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Foreword 



Jean Claude Derniame^ 

Software process technology is an emerging and strategic area that has already reached 
a reasonable degree of maturity, delivering products and significant industrial expe- 
riences. This technology aims at supporting the software production process by pro- 
viding the means to model, analyse, improve, measure, and whenever it is reasonable 
and convenient, to automate software production activities. In recent years, this tech- 
nology has proved to be effective in the support of many business activities not 
directly related to software production, but relying heavily on the concept of process 
(i.e. all the applications traditionally associated with workflow management). This 
book concentrates on the core technology of software processes, its principles and 
concepts as well as the technical aspect of software process support. 

The contributions to this book are the collective work of the Promoter 2 European 
Working Group. This grouping of 13 academic and 3 industrial partners is the suc- 
cessor of Promoter, a working group responsible for creating a European software 
process community. Promoter 2 aims at exploiting this emerging community to collec- 
tively develop remaining open issues, to coordinate activities and to assist in the dis- 
semination of results. The title “Software Process Modelling and Technology” [Fink94] 
was produced during Promoter 1 . Being “project based”, it presented the main findings 
and proposals of the different projects then being undertaken by the partners. The 
present book is more ambitious for two reasons: it is “principles oriented” and it is 
intended to reflect our common understanding of the key concepts. 

In order to produce it, we have adopted, from the beginning, an explicit “book writ- 
ing” process and we have also described it with one of the available formalisms. This 
is used as an example in Appendix C to illustrate the discourse and to defend the thesis 
that software process technology can be exploited in other related domains. Each chap- 
ter has specific editors and contributors, and contributions have been discussed and 
amended before being integrated. The global editing has been decomposed into two fac- 
ets, with the syntactic and semantic editing undertaken by Ali Kaba and myself, and a 
complete revision to transform our “Esprit English” into one more correct, with thanks 
to the IPG at Manchester for their enormous contribution. 

Nancy, France December 1998 



1. Coordinator of the Promoter and Promoter 2 Working Groups. Promoter is a research working 
group funded by the ESPRIT programme under reference WG 21 185. The members can be 
reached at promoter@loria . f r . 
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Chapter 1 

The Software Process: Modelling and Technology 



Editor; Carlo Montangero 

Contributors; Jean-Claude Derniame, Ali Badara Kaba, Brian Warboys 

1.1 Introduction 

Nowadays it is widely accepted that the quality of any product cannot be ensured simply 
by inspecting the product itself or by performing statistical quality control; quality is not 
only related to the product, but to the organisation and to the production process that is 
carried out. This view is the first tenet of Total Quality Management^ (TQM), a para- 
digm that guides enterprises in focusing on quality. TQM also puts forwards a second 
tenet, namely that quality is assured only if all the people involved in the organisation 
work with dedication and commitment; quality is excellence in all the aspects of an 
organisation. 

The software process defines the way in which software development is organised, 
managed, measured, supported and improved (independently of the type of support 
technology exploited in the development). Although they may exhibit different levels 
of sophistication in mastering their processes, all organisations involved in software 
development follow a process of some kind, implicit or explicit, reproducible, instru- 
mented, adaptable or otherwise, etc. Software houses and businesses in general (who 
increasingly consider software as a key competitive factor) have come to realise that the 
key to successful delivery (on time, on budget, with the expected quality) lies in the 
effective management of their software process. 

This emphasis on process provides the main justification of many standardisation ini- 
tiatives, as well as of the efforts to measure process maturity, like the Capability Matu- 
rity Model of the Software Engineering Institute (Carnegie-Mellon University) and its 
European counterparts, such as Bootstrap and SPICE, currently supported by the Euro- 
pean Software Institute in Bilbao. These convergent efforts reflect an evolution of the 
concept of software quality from the traditional verification and validation (V&V) 
approach towards process-focused environments. Underlying this shift is the conviction 
that quality improvement and cost reduction are best served by pre-certifying processes 
and then monitoring that these processes are adhered to. Increasing the probability that 



1 . The methods, systems and environments quoted in this chapter are discussed in some depth in 
the next ones; the impatient reader is referred to the index at the end of the volume. 

J.C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 1-13, 1999. 

© Springer-Verlag Berlin Heidelberg 1999 



2 1 The Software Process: Modelling and Technology 

software is built right in the first place is better than redoing work when WScV reveals 
faults. 

This book is devoted to quality management for software. The focus is on supporting 
the development process by the construction of explicit models and through the deploy- 
ment of automated support environments. The book does not attempt to compare, ana- 
lyse or propose improvements to existing processes or process design methodologies. 
Its main concern is with the core technologies and basic concepts underpinning soft- 
ware process modelling and software process automation, with a special emphasis on 
the mechanisms that support software process evolution. Software process management 
and Software process improvement are not central here, the reader is referred to sources 
such as [Hump90] for further reading in these areas. 

1.2 The Perspective of this Book 

We will rely on some well known concepts [McLe90] about manufacturing processes 
to introduce our point of view on the software development process. We do this in full 
awareness of the common argument that software development is not a manufacturing 
process, due to peculiarities such as the need for creative human participation and its 
lack of repetitive actions. Here we contend that it is helpful to stress similarities rather 
than differences, to understand production loosely so as to comprise the activities 
involved in software development, and hence to exploit the larger paradigm to put our 
problems in a broader perspective. 

Thus we argue that, like a manufacturing process, the software process consists of 
two interrelated processes, the production process and the management process. The 
production process copes with producing and maintaining the product, while the man- 
agement process provides the resources needed by the production process and controls 
it. This is rendered possible since the production process feeds-back to the management 
process information on its behaviour. These relations are depicted in Figure 1.1. The 
figure gives prominence to the relationships between the processes and the external 
environment. The request for the product to be developed comes from the external 
world, i.e. it is the external environment that justifies the existence of the production 
process. Moreover the management has to comply with current standards prevailing in 
the environment, i.e. the external environment indirectly influences the production 
process too. Finally, the process exploits technologies that also come from the environ- 
ment. 

The aim of this book is to consider the effect of a specific technology that is emerging, 
namely software process technology, on the general picture of Figure 1.1. 

The essence of Software Process Technology is that it allows integration of the pro- 
duction and the management technologies in a comprehensive work environment, a 
Process-sensitive Software Engineering Environment (PSEE), that supports the whole 
process. Figure 1.2 shows the impact of this new technology, illustrating how the PSEE 
implements, controls and enhances both the feed-back and the feed-forward paths by 
which the management process controls the production process. 
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Figure 1.1 The software process as a manufacturing process 




Figure 1.2 The impact of software process technology 

This approach is clearly rooted in the long tradition of the use of automation in soft- 
ware development, starting from the first assemblers back in the ‘50s down to the recent 
CASE tools and environments. 



1.3 Processes and Process Models 

Within a company or an application domain, the processes of different projects tend to 
follow common patterns, either because best practices are informally recognised or 
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because the community raises them to the status of (often de-facto) standards. Hence it 
make sense to try to capture these commonalities in a process representation, which 
describes these common features and fosters the cultural homogeneity of the commu- 
nity. 

During the last three decades, the study of software production processes has led to 
the development of various software life-cycle approaches that may be employed in the 
engineering of software. These include the Stage-Wise, Waterfall, Transformational, 
Evolutionary and Spiral models. The primary functions of a software life-cycle are to 
determine the dependencies between the stages involved in software development and 
evolution, and to establish the transition criteria for progressing from one stage to the 
next. These include completion criteria for the current stage plus choice and entrance 
criteria for the next. These life-cycle models help engineers and managers become 
aware of and gain an increased understanding of the software process, and to determine 
the order of global activities involved in the production of software. 

A limitation of these models, however, is that they are too coarse-grained, and that 
they do not address important process issues that are crucial for the success of software 
projects. For example: 

• Configuration management is critical yet how is the configuration management for 

product X to be integrated in the specific process for project Y? It is not unusual for 
a company to rely on an ad-hoc process, hard-wired in a tool, for configuration man- 
agement. 

• Identifying measures and metrics according to required quality assurance and control 

policies is fundamental to achieving high quality software products. But how are 
those measures and metrics to be integrated in the software production process? 

• Project management is essential for the success of a project. How should useful infor- 

mation be collected and presented to the project manager in order to have a global 
view of the actual process? 

• During maintenance all activities going from “Change Control Board” to “Bug Cor- 
rection” have to be properly coordinated. How is consistency guaranteed when two 
“correctors” work simultaneously on the same version of a configuration? 

• The anticipated benefits of module re-use have as yet not materialised. The potential 

for generic process definition, and the opportunities that this offers, remain unex- 
plored. 

The ultimate goal of software process technology is to reach the point where the proc- 
ess representation can be used to drive the actual process of software development. We 
designate such a software engineering environment a Process-sensitive SEE, abbrevi- 
ated to PSEE. As a first step, process technology introduces the notion of a process 
model, an abstract representation of a family of processes expressed in a suitable proc- 
ess modelling notation. A process model is a special kind of process representation, 
since it is expressed in a suitable /ormaZ/sm. In doing this, process technology makes 
use of the considerable experience with formal representation and model construction 
that is widespread in the computing community. 
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The goals that motivate the introduction of process models are manifold: they span 
from informal support (through increased understanding) to direct assistance in process 
assessment and improvement. In general, the availability of a (computer supported) 
model provides capabilities for process enforcement (i.e. direct support of actual per- 
formers, via control of their work, their coordination with others etc.); automation (i.e. 
automatic invocation of non-interactive tools); guidance (i.e. indirect support, like 
information on the current state of the process, the meaning of decision points, etc.). 
Notice that the availability of a precise model is paramount in raising the effectiveness 
of the latter, since it provides a non-ambiguous basis for communication about the proc- 
ess. 

Models play an essential role in process assessment and improvement: indeed, they 
provide a firm basis for process monitoring, since they convey a clear understanding of 
what can be observed and why, and for simulation, where the behaviour of a process 
can be studied at low cost with dry runs (i.e. without real performers or tools). Simula- 
tion and monitoring, together with model inspection, are powerful tools that allow use- 
ful model properties to be determined, i.e. they allow process validation. Models are 
also obviously necessary for process verification, where one proves formally the prop- 
erties of interest. 

To provide some real substance for these ideas, we now present an example. It is 
inspired by the exercise proposed at the 6th International Software Process Workshop 
in October 1990 [Kell91], and its evolution through to the 9th Workshop in the series 
[Pene94b]. The original purpose of the exercise was to provide a reference problem to 
compare different approaches to process modelling. 

1.4 A Simple Example: Software Change 

The original problem was scoped as a relatively confined portion of the software change 
process. It focused on the designing, coding, unit testing and management of a localised 
change to a software system, prompted by a change in requirements occurring either 
late in the development phase or during the maintenance and enhancements phase of the 
life-cycle. Our interpretation of the example assumes that the organisation in question 
produces new variants of a software system in response to Change Requests (see Figure 
1.3). The main activities identified in this model are: 

• Pre-Analysis: During this phase the project manager receives a Problem Report (PR) 
which is the description of a software problem occurring during a test phase. Follow- 
ing this PR s/he develops a schedule for the work to be undertaken for a software 
change in order to fix the bug described in the PR and assigns individual tasks to spe- 
cific staff members. The proposed schedule, as well as other information describing 
the problem, are provided in a Change Request (CR) which is sent to the analyst 
engineer. Analysis: This phase involves the modification of the design of the code 
modules affected by the requirements change. The modified design will be reviewed 
and ultimately implemented in code. Code modifications are also reported in the CR 
form which is then transmitted to the engineer responsible for configuration manage- 
ment (in a “waiting”-for-correction status). 
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• Configuration Management and Integration: this phase is divided into two steps. In 

the first step the CR is sent to the development engineer along with the impacted 
components. In the second step (after correction) integration of the modified module 
is performed and integration tests are applied to the new configuration. It is assumed 
that there is no configuration management tool involved in the process. 

• Development and Test: This phase involves the implementation of the design changes 

into code, compilation of the source code into object code and application of the unit 
test package to the modified code according to a well-defined strategy. During this 
phase, changes are also made to test plans and test packages. Like ISPW-6, we 
assume that the Development and Test phases concern only one engineer, e.g. there 
is no conflict problem when changes are made to a single module of code. The cor- 
rected module can be integrated into new releases (during the Integration step). At 
the end of this activity the CR becomes “fixed”. 




: Data flow 



PR: Problem Report 
CR: Change Request 



Figure 1.3 The process model for software change 



This informal description should provide an intuition of the complexity, in terms of 
activities, documents, and people, that even a small portion of the overall development 
process involves. The ultimate goal of the Software Process Technology is to master 
this complexity, via a deeper understanding of the process itself and consequently better 
automated support provided by a PSEE. The example will be further refined in Chapter 
4, where the crucial problem of process evolution, and hence of the support provided by 
the PSEE, is considered. 
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1.5 Process Modelling 

1.5.1 Basic Elements 

We can summarise the basic elements of a software process as depicted in Figure 1.4, 
which is freely inspired to the PCIS life cycle process support [Dern94], 

Has sub Has sub 




Figure 1.4 Basic concepts of process modelling 

• An activity is an atomic or composite operation, or a step of a process. Activities aim 

at generating or modifying a given set of artifacts-, they incorporate and implement 
procedures, rules and policies. Moreover, an activity is a concept with a strong func- 
tional flavour since it entails inputs, outputs, and intermediate results. Typical activ- 
ities are depicted as boxes in Figure 1.3. 

• The set of artifacts to be developed, delivered and maintained in a project is called the 
product. Figure 1 .4 indicates that there is usually some correspondence between the 
decomposition of activities into sub-activities and that of the product into sub-prod- 
ucts, but this is not mandatory. The example in Figure 1.3 shows that, besides the 
final software product, other products must be considered for a successful develop- 
ment, like Change Requests and Problem Reports. 

• A resource is an asset needed by an activity for it to be carried out. In our field, there 

are two resources of paramount importance: the performers, i.e. the human agents in 
the process, and the tools, i.e. the computerised agents that traditionally have been 
used in software development (specialised editors, compilers, etc.) or general pur- 
pose tools such as spreadsheets, diagram editors, etc. that can be used to manage the 
process. Tools are characterised by the operations they implement, their cost of use 
and their availability. 
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• Usually, tools are tightly connected to the activities in which they are used, while per- 
formers are indirectly linked to an activity via their roles, i.e. sets of responsibilities, 
obligations and concomitant skills (e.g. designer, project manager, reviewer, etc.). 
The character of the organisation impacts on the process indirectly via roles, and also 
directly via the directions (policies, rules, and procedures) that govern activities. 
Directions usually come in manuals, and therefore are structured. Software process 
technology has the potential to enforce these directions, by providing computer sup- 
port to guide and control the performers’ initiatives, to coordinate their activities, to 
support cooperation, automation, etc. The ultimate goal of this greater enforcement 
is to raise the level of confidence in the product quality, since it ensures greater 
adherence to the process quality standards. 

Resources and organisational factors do not figure prominently in Figure 1.3. This is 
a consequence of the high level of the description, as discussed below. 



1.5.2 Process Model Levels 

Processes can be represented at increasing levels of detail, capturing smaller and 
smaller families of sub-processes, corresponding to narrower and narrower concerns. 
Usually, the most generic descriptions, such as life-cycles, are largely informal. At the 
other extreme, operational process support needs an executable formal description at a 
detailed level. In between, there are a number of intermediate levels. More precisely, 
we will make the following distinctions. 

• A life-cycle is a loose, informal representation of a software process. Well known 

examples are the Waterfall [Royc93], Spiral [BoehSl] and Transformational 
[Balz83] life-cycles. The purpose of these models is to address global methodologi- 
cal issues, e.g. specify before coding (the waterfall approach), assess risks before 
specification (the spiral approach) or go seamlessly from specification to code (the 
transformational approach). These representations apply in many companies and 
application domains. 

• A generic process model is also an abstract representation, which can be used in many 

similar projects and organisations, sharing common properties and characteristics. 
For instance, it may be a formal representation of a life cycle, or of a software re- 
engineering process. The example of Figure 1.3 may be considered a generic process 
model. 

• A customised process model is more detailed, and is usually derived from a generic 

model taking into account specific local characteristics, e.g. the application domain. 
There usually are different levels of customisation, at increasing levels of detail and 
formality. Examples may be the following : 

- standard processes, like ESA PSS-05 (see Chapter 2) and Mil-Std 2915; 

- the customisation of a standard, to fit the needs of a specific organisation ; 

- further customizing to fit the needs of a specific project in the organisation. 
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• An enactable process model is the most detailed level of customisation: it defines the 

process to he followed in a specific project, and, from our perspective, it is a repre- 
sentation ready to he loaded into a machine in order to provide automatic support to 
the people involved in the development process. 

• Finally, an enacting process model is a model in place, supporting actual develop- 
ment: to do so, it holds some kind of representation of the current development state. 

The terminology may need some comment. Following Dowson [Dows94], we distin- 
guish between the domain of process performance and that of process enactment. The 
former concerns the act of participating in a process, hy people and tools. The latter is 
related to the act of automatically driving the process, i.e. interpreting the most detailed 
process model. Tools and people, in so far as they are controlled hy the environment, 
also belong to the process enactment domain. In other words, while a process is per- 
formed in the real word, it is enacted in the abstract world of the computerised model. 
Since computers are part of the real-world, it goes without saying that enactment is part 
of performance. 

It is precisely because they belong to both domains, that, contrary to what many fear, 
human performers can still contribute creatively to development, even when working 
under the constraints of enactment in a PSEE. This multiplicity of domain membership 
is one aspect of the complexity of software processes. Another is captured by the idea 
of multiple views of the process. 



1.5.3 Process Model Views 

Process models are often not intended to convey an understanding of the whole process, 
but only of a particular view of interest. Typical examples are: 

• the activity model, that focuses on the types, structure and properties of the activities 

in the process and their relations: this view is relevant, for instance, to the project 
manager for scheduling purposes; 

• the product model, that describes the types, structure and properties of the software 

items of a process; this view may be of interest also to the user, e.g. to understand 
which kind of documentation will be delivered with the software system; 

• the resource model, that describes the resources either needed or supplied to the proc- 

ess, which again is relevant from a managerial perspective; 

• the role model, that describes a peculiar set of resources, namely the skills that per- 
formers supply and the responsibilities they accept: this is relevant to the organisa- 
tion and the quality assurance personnel, besides other performers. 

Obviously, one view cannot be defined without using concepts from the others. Eor 
instance. Figure 1.3 essentially provides an activity view, but needs some elements of 
the product view to be meaningful. On the other hand, a product view pertaining to fig- 
ure 1.3 would essentially convey information about product structure, reducing the 
activities to mere check-in and check-out. 
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Finally, we need to point out that there are two trends with respect to the idea of dif- 
ferent views in a comprehensive model: the first one, inspired hy the experience with 
database management, insists on the consistency of the different views, and considers 
the views as sub-models of a single global model. The opposite approach is taken, for 
instance, in [Nuse93]; this work assumes as a starting point a collection of (possibly 
inconsistent) views, together with automatic support to connect them and to help the 
user in dealing with the inconsistencies. 



1.6 Process-sensitive Software Engineering Environments 

As shown in Figure 1.2, the key feature of software process technology is computerised 
process support, i.e. the availability of a process model and the appropriate means to 
define, modify, analyse and enact it. Figure 1.5 highlights the essential components of 
this support. A PSEE is controlled by a process engine, i.e. an interpreter of a process 
modelling language. Essentially, the goal of this engine is to control the information 
flow among the performers at their workstations, according to the process model. The 
model is stored in a repository, together with the product definition and relevant infor- 
mation on the process status. This picture is intended to convey the importance of two 
levels of memory in the PSEE: besides the long-term global storage capabilities offered 
by the repository, the workspaces (i.e. the sets of computing resources that performers 
use when playing a role in an activity) offer medium-term storage capabilities, either 
private or shared cooperatively by groups of performers. The PSEE also has the ability 
to share data with the rest of the world, by import/export channels, that allow the 
exchange of products and models in a suitable communication format. 
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Figure 1.5 Conceptual architecture of a PSEE 



The picture does not show how tools are exploited and deployed in the workspaces 
via their descriptions in the model; this is left implicit. The broken line from the process 
engine to the communication layer indicates that the process engine controls the PSEE, 
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essentially controlling the information flow between the repository and the workspaces, 
amongst the workspaces and between the users and their workspaces. 

The similarity of this conceptual architecture and that of a general purpose computer 
is not casual; a PSEE is an abstract machine for software development, where the enact- 
ing model plays the role of the stored program, the repository that of the main memory, 
the workspaces that of the machine registers, and the tools are the primitive operations. 
A major difference is that of time-scale for the involved phenomena, fractions of a day 
for the basic operations of software development, fractions of microseconds for that of 
a computer. 

It is interesting to contrast this picture with the reference architecture for software 
engineering environments articulated in the so-called toaster model defined by ECMA- 
NIST [ECMA91]. There is a clear shift in focus: Figure 1.5 is essentially related to a 
part of the ECMA model, namely to the process services. The two approaches are com- 
plementary: indeed, the ECMA model may seen as the basis of the organisation of the 
communication layer and its relations with the repository, workspaces and tools. 

1.7 Meta-Process 

To conclude this introductory chapter, we stress the need to consider two facets in a 
modern software production environment: 

• a performing process P, i.e. the real-world production process including human 

actors, CASE tools, etc. which encompass all activities aiming to develop the soft- 
ware product, and 

• a process model PM, which is a representation of the real world, and captures the cur- 
rent state of the activities for guiding, enforcing or automating parts of the production 
process. 

Ideally, P and PM should be perfectly aligned, in the sense that the internal state of 
the process model is a faithful representation of the actual state of affairs in the real- 
world, i.e. P is an instance of PM. However, any real-world software process is a crea- 
tive process involving numerous human actors; it is dynamic and evolves continuously, 
and cannot be reduced to the programming of automata. A degree of inconsistency 
between P and PM is thus inherent in the nature of things and poses the risk of disas- 
trous consequences for final product quality. The process model must coordinate activ- 
ities and manage the information flow, and it must adapt to any evolution of the real 
world process. This, as will be seen, is a major issue. 

Madhavji identifies several reasons for the pressure to change the software process 
[Madh91]; 

• the process may be faulty; 

• the process may be missing certain important steps, rendering it ineffective; 

• the process model may be generic and needs to be customised in order to obtain spe- 

cific results; 
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• the assumptions under which the process model was engineered are no longer valid; 

• the dynamics of politics, human beings and technology can have an effect on the soft- 

ware process. 

As a result, the real-world process and the process model must evolve jointly, in a 
coherent manner. To illustrate, the reader is referred to Figure 1.3. Imagine that the peo- 
ple involved in the change process report their experiences, and this feedback is ana- 
lysed by the project manager who draws the conclusion that it is very difficult to ensure 
consistent integration in order to make a new release of software covering several par- 
allel changes, since the current model does not allow parallel development. Conse- 
quently it is impossible, for instance, for two analysts to make parallel studies of a 
problem report, or even to split their job in two (e.g. one analyst for design modifica- 
tions and one for test package modification). The project manager thus decides to 
enhance the existing model, e.g. by extending it to allow parallel analysis and develop- 
ment. 

The lesson to be derived from this scenario is that the evolution of a software process 
is itself a full process: the project manager will need to involve the services of process 
modeller to develop an enhanced model, validate the new model, and then decide when 
to start enacting it. This higher-order process is called the meta-process. Such a process 
would include steps for changing the real-world process and others for introducing 
changes in process models. Its main role is one of assuring that P and PM remain con- 
sistent. These issues will be explored in detail in Chapter 4. 



1.8 Conclusion 

This book concentrates on conceptual and technical aspects of process modelling and 

software process technology. Central to this purpose are questions such as: 

1 . How can we articulate process models in order to represent, analyse and validate soft- 
ware processes, and also to enact them. What are the required features of such for- 
malisms? Is it possible to have a single language or do we need a multi-paradigmatic 
approach? These questions are addressed in Chapter 3. 

2. Having a formalism to describe a process, how can we design a process model? How 
can we validate it? How can we change it and/or improve it, and when? What is the 
life cycle of a process model? These questions are addressed in Chapter 4 which 
focuses on the fundamental concept of the meta-process and proposes a reference 
model. 

3. Which kind of I.T. architecture is best suited to support software processes and can 
we define a reference model for Process-sensitive Software Engineering Environ- 
ments? These issues are addressed in Chapter 5. 
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4. Following on from Chapter 5, which underlying mechanisms are required to support 
the coordination needed in software development, which is increasingly performed 
over a geographically distributed area? Chapter 6 deals with cooperation control in 
PSEEs; more precisely it addresses the transaction models needed to support coop- 
erative processes such as software processes. 

5. Software processes are not purely technical processes; their enactment entails collab- 
oration between humans and machines. What is the role of human in the process? 
Chapter 7 is an attempt to “rehumanise” the software process by adopting a “human- 
centred perspective”. It may be seen as providing a general critical commentary on 
the process technology paradigm. 

The book is completed with a concluding chapter which summarises key issues and 
research trends. The book is also supplemented by annexes, such as an index and glos- 
sary. An important appendix proposes an assessment framework for PSEEs. This 
framework is intended to help in selecting either process support tools or a PSEE, in the 
light of the particular circumstances of a development context. A further appendix 
addresses the wider validity of the paradigm elaborated in the book. It provides a 
detailed example of process modelling in a different context, namely the collaborative 
writing of a book. There is an extensive bibliography which is supplemented by identi- 
fying key readings in each of the topic areas covered by this book. 




Chapter 2 

Software Process — Standards, Assessments and 
Improvement 



Editor; Wolfgang Emmerich 

Contributors; Anthony Finkelstein, Alfonso Fuggetta, Carlo Montangero, 

Jean-Claude Derniame 

2.1 Introduction 

Software engineering and software process improvement standards are gaining more 
and more attention. Why is this? First, standards are recognised by the software industry 
as a way for transferring good practice into industrial use. Agencies procuring software 
are focusing on standards as they want to ensure that a target level of quality (associated 
with the standard) has been followed during the development of the software and is 
hence reflected in the quality of the software itself. Moreover, standards are used as the 
basis against which organisations and/or software products are certified. Finally, if two 
organisations collaborating in the development of a software product follow the same 
standards, then cooperation will be considerably simplified. 

In the last few years there have been a number of standardisation initiatives aimed at 
software development organisations. Three different directions can be distinguished;- 

a) Definition of standard processes. These focus on the key points to be addressed to 
provide an effective and well-defined quality manual. ISO 9000 [lS091b], the ESA 
process standard PSS-05 [Mazz94], and ISO 12201 [1S095] are some examples. 

b) Definition of assessment method. These provide guidelines to evaluate the maturity 
of the process carried out by an organisation. The Software Engineering Institute’s 
Capability Maturity Model (CMM) [Hump90], the European Bootstrap Method 
[Kuva94], and ISO 15504 [lS097b] are examples of these. They are all based on 
some model of maturity. These models identify different maturity levels, and an 
assessment method which locates an organisation at one of the maturity levels. 

c) Definition of methods supporting the improvement of an existing process. For 
instance, the Quality Improvement Paradigm (QIP) [Basi93] is based on the idea that 
process improvement can be accomplished only if the organisation is able to learn 
from previous experiences. During the execution of a project some suitable measures 
are performed, and the collected data are analysed and packaged for future uses. 
Some assessment methods also provide improvement guidelines 

J.C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 15-25, 1999. 
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2.2 Standard Processes 

2.2.1 ISO 9000-3 

The International Standardisation Organisation (ISO) has defined a number of stand- 
ards that are generally applicable to all production processes. ISO 9000 [IS09Ib] sup- 
plies a set of standards for quality management not only for software development, but 
for any of production activities. Organisations are supposed to set up a quality system 
in order to supervise all phases of a production and delivery process. A quality system 
defines requirements for the development process of that organisation. Some of the 
activities carried out by the quality system are:- 

a) auditing the projects to ensure that quality controls are respected, 

b) improving the quality system itself, and 

c) providing input to the development group, such as new notations, procedures, and 
standards; producing reports to the high-level management. 

The details of the quality system are contained in a quality manual which contains 
standards for the quality and the development activities. 

When a new project is planned, the project manager identifies the quality issues rel- 
evant for the project and extracts them. All procedures and standards need to ensure that 
the defined quality levels are extracted from the quality manual and that a quality plan 
is written that identifies the means for quality control. 

ISO 9000 has been specialised for software production because it has been recognised 
as different from general purpose production processes. The result of this customisation 
is ISO 9000-3 [IS09Ib]. The basic ideas are the following;- 

a) Quality control should be performed during all the phases of software production, 
procurement and maintenance. 

b) The purchaser should strictly cooperate with the software product supplier. 

c) The supplier should define its quality system, and ensure that its entire organisation 
understands and implements the system. 

ISO 9000-3 does not impose a specific life-cycle model. It also does not provide spe- 
cific methods for evaluating the quality assurance capabilities of an organisation. It 
therefore can be coupled with other more specific approaches, such as Boehm's Spiral 
model [BoehSS]. 

ISO 9000-3 can be used in contractual situations, when the purchaser and the supplier 
establish that some quality elements will be part of the supplier’s quality system, and 
the supplier commits to follow the quality principles defined in the standard. Moreover, 
it can be exploited in non-contractual situations, when the supplier voluntarily applies 
the quality standard in order to be competitive and to ensure the quality of its products. 
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2.2.2 PSS-05 

The European Space Agency (ESA) has adopted PSS-05 [Mazz94] as a software engi- 
neering standard that is binding for all software that is either procured or developed in- 
house hy ESA. The standard takes two different perspectives: it contains standards, 
guidelines and recommendations concerning the software to be defined, implemented, 
operated and maintained; it also determines procedures that are to be used to manage a 
software project. 

The standard is based on the concept of practices. Practices in PSS-05 are either man- 
datory, recommended or guiding. A mandatory practice must be followed without 
exception in all software projects. Recommended practices may or may not be fol- 
lowed. However, a justification has to provided if a recommended practice is ignored. 
Guideline practices are less crucial; no justification is needed if they are not followed. 

PSS-05 does not prescribe a particular life-cycle model. However, a life-cycle model 
adopted for a project must be defined in a management plan and must include the fol- 
lowing mandatory phases :- 

a) definition of user requirements, 

b) definition of software requirements, 

c) definition of architectural design, 

d) detailed design and production of code, 

e) transfer of the software to operations, and 

f) operations and maintenance. 

Practices related to products detail the products that are developed in these stages and 
how that development should be performed. The degree of abstraction of these product 
practices varies to a large extent. Some practices are very high-level, an example of 
which is: “all known user requirements shall be included in the user requirements doc- 
ument. Others are fairly concrete, such as “for incremental delivery, each user require- 
ment shall include a measure of priority so that the developer can decide the production 
schedule’". 

Practices related to management procedures are of concern throughout the different 
phases identified earlier. The purpose of these is to ensure that projects are managed in 
such a way that the product is built within budget, according to schedule and with the 
required quality. The standard recommends the mandatory definition of plans for:- 

a) software project management, 

b) software configuration management, 

c) software verification and validation, and 

d) software quality assurance. 

To date, the use of PSS-05 is not confined to ESA and its contractors. It is being used 
in the automobile industry and for procurements in various European defence projects. 
Currently, PSS-05 is being used as one basis for the ISO 15288, a new system engineer- 
ing standard [IS097a]. 




18 2 Software Process — Standards, Assessments and Improvement 

2.2.3 ISO-12207 

ISO 9000 is a standard for quality management and improvement, but it provides little 
concrete guidance as to how software engineering processes should be performed. The 
ISO standard 12207 “software life cycle processes” [IS095] is more concrete in that it 
identifies mandatory processes, tasks and activities for software life cycles. Unlike 
PSS-05, which has been explicitly defined for one particular domain, ISO-12207 is 
intended to be applicable to software development in a broad range of application 
domains and for a variety of different software systems. 

Any ISO standard contains a normative and an informative component. The norma- 
tive component in ISO-12207 determines mandatory practices that ought to be followed 
for a particular development effort to be compliant with the standard. The informative 
component identifies rationales for the practices required by the standard and explains 
their application. 

ISO-12207 covers the entire life-cycle from “conceptualisation of ideas through 
retirement”. It considers the software life-cycle from different levels of abstraction. At 
the highest level, it identifies a number of processes. Three different categories of proc- 
esses are identified;- 

a) primary life-cycle processes are conducted by prime parties, i.e. those that initiate or 
perform the development, operation or maintenance, 

b) supporting life-cycle processes, for instance configuration management; these sup- 
port primary processes in order to contribute to the success and quality of the project, 
and 

c) organisational life-cycle processes that are employed by an organisation to establish 
and implement the underlying structure of the life-cycle, such as management and 
process improvement. 

Processes are decomposed into activities. The acquisition process, for instance, is 
decomposed into activities for initiation, request for tender, contract preparation, sup- 
plier monitoring, and acceptance and completion. Activities are further decomposed 
into tasks. The request for tender preparation activity, for instance, encompasses tasks 
determining system requirements, the scope of the system, instructions for bidders, gen- 
eral terms and conditions, control of subcontracts and technical constraints. 

As the standard is meant to be applicable in many different domains, it covers a vari- 
ety of processes, activities and tasks. In order to define customisations of the standard 
for a particular domain, organisation or project, the normative part of the standard 
includes a tailoring process. It defines how the standard is to be adapted and indicates 
those processes, activities and tasks that might he omitted. Moreover, it allows proc- 
esses, activities and tasks to be added, provided that they are specified in a way that is 
compliant with the standard. The ability to tailor the standard allows its application in 
a number of different settings, such as waterfall, evolutionary, incremental and spiral 
process models. 

The overall process model defined by ISO-12207 is decomposed in a functional way 
into a three level hierarchy consisting of processes, activities and tasks. A weakness of 
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the process definition is that it only implicitly identifies the products that are to he pro- 
duced. Moreover, coordination and dependencies between tasks are only implicitly 
defined. Finally, tasks such as systems requirements are considered as atomic in the 
decomposition hut are still rather coarse-grained. 

2.3 Assessment Methods 

2.3.1 The Capability Maturity Model 

In the late 1980s, the Software Engineering Institute started its well-known work on 
software process assessment. The work was motivated by the observation that the first 
step for consolidating and improving processes is to assess them [Hum88, Hump90]. 
The SEI supplies two different assessment programmes [Paul95]:- 

a) Software-process Assessment Program. This is directed to those organisations that 
want to evaluate their process in order to improve it. 

b) Software Capability Evaluation Program. This can be used by customers (in partic- 
ular, US government agencies) to assess the processes and maturity levels of their 
contractors. 

These two programmes share, to a great extent, the same assessment method. In the 
first case, the result of the assessment programme is a document that provides the organ- 
isation with some suggestions on how to conduct process improvement. In the second 
case, a grade ranging on an ordinal scale from 1 to 5 is calculated. This grade quantifies 
the maturity level of the organisation. In general, in the first case the assessment is self- 
performed by the organisation, possibly under the assistance of the SEI; while in the 
second case, the assessment is performed by an external independent team from the 
government or the customer. 
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Figure 2.1 The Capability Maturity Model 

In order to assess the maturity of the organisation and to identify the issues to be 
addressed for improving its processes, the SEI defined a maturity model, called the 
Capability Maturity Model (CMM), shown in Figure 2.1. This model defines five levels 
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of maturity for the software industries. It then identifies a set of characteristics that 
organisations at each level should normatively possess. Moreover, a set of goals is 
defined that organisations should pursue in order to reach the next level. 

a) The lowest level is the initial level. Success of organisations at this maturity level 
depends on the skills and individual efforts of developers rather than on properly 
defined and managed processes. 

b) At the second level processes are repeatable. At this level of maturity, the organisa- 
tions establish project management policies and procedures to carry out a project. A 
quality assurance function controls that the policies and the procedures are being 
practised.This discipline ensures repeatability of earlier success on similar projects. 

c) At the third level (the defined level) a standard software process is defined. It defines 
project management and software engineering processes, and it is tailored to each 
project. An organisation adopting and tailoring, for instance PSS-05 or ISO 12207, 
would be at this level. 

d) At the fourth level (the managed level) the process and product quality is measured, 
predictable and quantifiable. By using these measures, the managers can identify the 
causes of exceptional events and can correct the situation. 

e) At the fifth level (the optimizing level) the process is continuously improved on the 
basis of quantitative feedback from earlier instantiations of the process. Process 
improvement is obtained by introducing new methods and new technologies, and it 
is planned like the ordinary management activities. 

The CMM achieved great industrial recognition after the US Department of Defence 
adopted it and required its contractors to have a defined process. It has been largely 
applied throughout the US and also was customised for small organisations [Brod97]. 

The Software-process Assessment Program starts with training the assessment team. 
After that, the team selects some representative project(s) of the organisation to be 
assessed. The members of the selected projects complete the SEI questionnaire, and are 
interviewed by the assessment team. The team uses the questionnaire and the interview 
to prepare a report, which identifies weaknesses of the organisation. The solution and 
guidelines for its implementation are outlined. To obtain real results from the assess- 
ment, high-level management needs to endorse the assessment. This will encourage 
those participating in the assessment to believe seriously that their suggestions will be 
taken into account and will influence the actual improvement of the development proc- 
ess. 

The main drawback of the Software Capability Evaluation Program is that it tends to 
oversimplify an organisation by constraining it into a five level classification. The clas- 
sification itself is based on common sense, but does not have a scientific foundation. 
The algorithm used to evaluate the scores is based on the idea that an organisation, 
which holds some characteristics of an higher level, cannot profit from these character- 
istics if it does not have all the characteristics of the lower levels. However, even in its 
simplicity, the CMM constitutes the most interesting attempt to analyse software proc- 
esses that has been developed so far. 
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2.3.2 Bootstrap 

The European Union funded Bootstrap project funded started in 1989. Its mission was 
to fertilise the ground for introducing modern Software Technology into industry 
[Kuva94]. 

The project was devoted to defining a framework for assessing European industries 
in different sectors, such as hanking, insurance and administration, and for promoting 
process improvement. The basic idea (that is also found in the SEI approach) is that 
technological innovation is not effective if it is not coupled with a careful definition of 
the methods used for building solutions, and if it is not carried out within a well organ- 
ised process. Basically, Bootstrap is an improvement of the SEI approach to process 
assessment and improvement, which takes some ideas coming from the ISO 9000-3 
standard into account. In particular. Bootstrap supplies: 

a) A detailed hierarchy of process quality attributes, based on the ISO 9000-3 guidelines 
on quality management. 

b) An enhanced version of the SEI questionnaire. 

c) A method, refined from the CMM, for assessing the maturity level of an organisation. 

While the first version of the SEI questionnaire offers only yes/no answers, the Boot- 
strap approach provides four different choices: absent/weak, basic/present, significant/ 
fair, and extensive/complete. ^ Moreover, the Bootstrap questionnaire is based on a 
defined hierarchy of quality attributes. The Bootstrap method for obtaining the score of 
an organisation is more flexible than the SEI method. It is based on the same five matu- 
rity levels, but its goal is not to compute a unique score for the organisation; instead, it 
allows a level of maturity to be determined for each quality attribute. In this way, organ- 
isations can identify the weaknesses of their process and can concentrate on fixing 
them. 

The Bootstrap assessment method can also be used to evaluate whether an organisa- 
tion is ready to obtain the ISO 9000 certification. No specific maturity level is specified 
for this certification. ISO 9000, in fact, requires that organisations use some statistical 
techniques that are for level 4. On the other hand, it does not requires the use of specific 
methodologies, nor specifies how efficient and effective they have to be. Organisations 
only have to prove that they have some methodologies and use them. For these reasons, 
an organisation that is between levels two and three could obtain the certification. A tool 
that calculates a certification level is being developed, and will be part of the Bootstrap 
methodology. 

2.3.3 SPICE 

SPICE (Software Process Improvement and Capability dEtermination) [Rout95] is a 
project funded by the International Committee on Software Engineering Standards 



1. This idea has been partially taken into account in the new version of the SEI questionnaire, in 
which answers like: “I do not know”, and “the question is not applicable” are allowed. 
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(ISO/IEC JTC 1/SC7). Its goal is to build an international standard for software process 
assessment, covering development, acquisition, management, customer support and 
quality, and also human concerns and technology transfer. It is based on knowledge 
acquired using existing assessment methods, like CMM, Bootstrap, and ISO 9000-3. 
The result of the project is the new ISO 15504 [IS097b] standard. It comprises a set of 
documents that will guide the; 

a) high level definition of goals and fundamental activities that characterise good soft- 
ware engineering, graded according to levels of capability, 

b) training of the assessors, e.g. by establishing the procedures for assessors’ qualifica- 
tion, 

c) process assessment and improvement phases, 

d) determination of the capability of an organisation, based on the results of the assess- 
ment, 

e) understanding of business risks when considering the development of a new software 
product or service, and 

f) generation of target profiles and maturity models for process improvement. 

2.3.4 Summary 

The approaches we have discussed here are used for assessing the capabilities and matu- 
rity of individual engineers or organisations. The assessments are intended to provide 
feedback as to how to improve processes. Kellner et. al. suggest in [Kell96] that process 
improvement processes are cyclic and that they have their foundation in the Shewhart 
cycle [Shew39], further developed by Deming [Demi94]. 

The SEI has developed an organisational reference model for cyclic software process 
improvement initiatives [McFe96]. This model consists of five phases; Initiating, Diag- 
nosing, Establishing, Acting and Leveraging and is referred to as the IDEAL model. 
The IDEAL model can express the assessment orientated methods we have discussed 
in this subsection as well as the improvement methods that we describe in the next. 

2.4 Improvement Methods 



2.4.1 Quality Improvement Paradigm 

The Quality Improvement Paradigm [Basi93, Basi94a] has been proposed by the SEE 
(Software Engineering Laboratory) of The University of Maryland to perform process 
improvement. The basic idea is that improvement is a continuous process, that is com- 
posed of the following steps;- 

a) characterisation of the project and its environment, 

b) planning a set of goals and the appropriate process models, methods, and tools for 
achieving these goals, 

c) execution of the process according to the defined goals, development of the product, 
and collection and analysis of data for feedback purposes. 
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d) analysis and packaging of data collected at the end of the project for use in future 
projects. 

Two tools are used for performing the steps described above: the Goal/Question/Met- 
ric (GQM) and the Experience Factory Organisation. GQM is used during the planning 
phase. It facilitates the definition of goals and suitable metrics for each of them. These 
will guide the execution of the process. The Experience Factory Organisation is an 
organisational structure that supports the packaging activities. 

The quality improvement paradigm teaches how to set-up a continuous improvement 
process, taking into account previous experiences. It is based on the assumption that the 
organisation is able to define a process model, is confident with tools and procedures 
for collecting metrics, that it manages a repository of data from previous projects, and 
so on. Therefore, the quality improvement paradigm can be profitably used by mature 
organisations, which are already aware of their process, in order to become more sensi- 
tive to the lessons learnt on the way. 

2.4.2 The Personal Software Process 

The Capability Maturity Model evaluates and rates the maturity of software processes 
at an organisational level. However, an important factor which determines the produc- 
tivity and quality of products is the maturity and capability of the individual developer. 
Motivated by the success of the CMM, the SEI has recently started work on the Personal 
Software Process (PSP) [Hump95, Hump96, Hump97]. The PSP is aimed at guiding 
individual engineers to improve their personal productivity, and hence the quality of the 
overall processes they contribute to. Engineers are introduced to the PSP by means of 
ten small exercise programmes. 

The PSP defines four levels of maturity and identifies the steps needed for reaching 
the next higher maturity level: - 

a) PSPO - Personal Measurement 

b) PSPl - Personal Planning 

c) PSP2 - Personal Quality 

d) PSP3 - Cyclic Process 

Many considerations of the CMM also apply to the PSP. In order to improve the 
maturity of individual developers, their performance has to be assessed in the first place. 
At the first level (PSPO), engineers are taught how to measure their development time 
and the defects they have injected and removed. Moreover, in PSPO engineers are intro- 
duced to coding standards, size measurements and a form for proposing improvements 
to their personal process. 

At level PSPl, engineers learn techniques for estimating size and development time 
on the basis of data they have gathered during PSPO. Moreover, they learn how to plan 
tasks and schedules. 

PSP2 introduces the management of defects. At lower levels, engineers will have 
gathered defect data. In PSP2, engineers use this data to construct checklists in order to 
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identify those defects they are likely to make. Engineers then use the checklist to con- 
sciously review their designs and their code against them. Engineers, therefore, learn 
that an individual focus on quality is important. By using these checklists, their skills 
will improve. 

In order to scale the approach from the small examples used in the exercises to real 
projects, the PSP has to be applied in a cyclic manner. A constant monitoring of injected 
and removed defects and constant reviews of the defect checklist is supposed to lead to 
improvements of personal quality. 

The PSP has been applied on a number of undergraduate, graduate and industrial 
courses. The following results have been obtained from a total of 104 engineers, half 
from industrial software organisations. The overall productivity improvement (meas- 
ured in lines of code per hour) is reported in [Hump96] to be about 20%. However, a 
notable difference in effectiveness was observed in the productivity improvements 
between undergraduates and more experienced engineers. While some undergraduates 
improved their productivity by as much as 420%, some mature engineers experienced 
performance degradations due to the additional overheads of estimation and reporting 
introduced through the PSP. 

Humphrey reports that quality, measured in terms of the number of defects injected, 
improved regardless of the experience levels of engineers. On average, the total num- 
bers of defects during his PSP trials decreased from 140 defects per KLOC in the first 
programming exercise to 49 defects/KLOC. Defects found during compiling decreased 
from 80 to 12 defects/KLOC. The decrease rates were higher for students without 
industrial experience, but even for engineers with 20 years of experience quality 
improved. 

To summarise, the PSP is an interesting approach for improving quality and produc- 
tivity of students and young engineers. The improvement is achieved through teaching 
an explicit focus on the process that is used for developing software. The SEI has pro- 
vided empirical evidence that the PSP improves both productivity and quality, which 
justifies teaching the PSP in both academia and industry. 

2.4.3 Total Quality Management 

Total Quality Management is not a specific and pre-defined methodology for process 
improvement. It is a generic paradigm that guides organisations in focusing on quality 
[Eeig91]. Its tenets are that quality is not only related to the product, but also to the 
organisation and to the production process that is carried out. Moreover, it argues that 
quality achievement is obtained only if all the people involved in an organisation work 
to obtain it; quality is excellence in all the aspects of an organisation. The management 
of quality enjoins a continuous and never-ending process of improvement. Process 
improvement can be carried out by performing big improvement steps followed by long 
periods in which no change is done, or by performing many little steps. The first 
approach is known as the Western approach, typified by managers who strive to achieve 
dramatic jumps by introducing new technologies and employing large amounts of 
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money in research and development. The latter approach is the Japanese approach, or 
kaizen, in which incremental daily improvements are sought using common sense and 
simple technology. 

TQM can he pursued using both approaches. However, a powerful approach can be 
obtained by combining the two, with big jumps realised through major innovations 
complemented by the pursuit of incremental changes between consecutive jumps. 

2.5 Standards and Software Process Technology 

Software engineering standards, such as ISO-12207 and ESA PSS-05, are rather gen- 
eral. They are written in a way that they can be customised towards the need of a par- 
ticular organisation or project. ISO-12207 even explicitly defines the process with 
which it is supposed to be customised. This refinement and customisation of a standard 
is in itself a process capable of being modelled, and we believe that the process model- 
ling principles, methods and techniques discussed in the following chapters of this book 
are applicable to the problem of refining standards. 

Software engineering standards only provide normative references. These are not 
directly applicable in a software engineering process. In order to guide software engi- 
neers in following standards they have to be automated, at least partly. This automation 
should help engineers to comply with the standards, check whether the documents are 
stmctured in a way prescribed by the standards and enable cooperation between differ- 
ent engineers in a way that is prescribed by the standard. The architecture of an envi- 
ronment needed for such automation will be similar to those discussed for process- 
sensitive environments later in this book. 

The standards we have looked at are all defined in natural language. Often the stand- 
ard is defined following a rigid structure, and the practices to be followed are explicitly 
highlighted. However, as one would expect from a natural language text, the standards 
are rather informal, ambiguous and inherently inconsistent. We believe that any attempt 
to automate the handling of standards in software engineering environments demands 
the formalisation of these standards. Again, the process modelling languages discussed 
in this book, and also the previous Promoter book [Fink94], are highly applicable to 
providing this formalisation. 
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Process Modelling Languages 
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3.1 Introduction 

This chapter deals with the requirements and proposed solutions for process modelling 
languages (PMLs). Process modelling is a very diverse and complex area and the 
requirements for the support of modelling and execution are both technical (e.g. for 
expressiveness, abstraction, and multiple perspectives) as well as non-technical (e.g. for 
commercial support). 

As mentioned in Chapter 1, a PML expresses software production processes in the 
form of a process model, being a computer-internal description of an external process. 
In the last 10 years, many PMLs have been proposed, implemented and experimented 
on without any real general agreement or standardization among them. 

Nevertheless, general agreement is emerging (see Chapter 1, for instance) on identi- 
fying the primary process elements such as activities (tasks), products, roles, tools, 
agents, and evolution support. A first basic requirement is that these concepts have to 
be captured by the language. The first chapter has also introduced the notion of the 
meta-process (explored and described in more detail in Chapter 4) which provides a sec- 
ond basic requirement for the PML in that each meta-process phase, such as Elicitation, 
must be supported by a language that allows the model to be expressed at the appropri- 
ate abstraction level. 

Each process element, i.e. tasks, roles, products and so on, needs to be described. 
Other elements playing a secondary role in the context of a process model are the 
notions of work contexts, tool views, and user views. Finally, cooperation models, ver- 
sioning and transaction, and quality models have to be described. In this chapter we will 
distinguish between the primary and secondary elements. 

Now a PML can be formal, semi-formal, or informal. A formal PML is one which 
is provided with a formal syntax and semantics. Semi-formal languages usually have a 
graphical notation with formal syntax, but not formal semantics i.e. not being executa- 
ble. Natural languages, such as English, may be used as informal PMLs. In this chapter, 
the emphasis is on formal PMLs, as they provide support for formal verification and 
analysis, simulation (i.e. “dry runs”), and execution (“wet runs”). 

J.C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 27-52, 1999. 

© Springer-Verlag Berlin Heidelberg 1999 
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The fundamental design challenges are thus: 

1. Should we have a small kernel PML, and many specialised sub-PMLs for process 
sub-domains, or should we have one large PML, with sub-PMLs as views? And what 
about interoperability in federated systems, with sub-PMLs and related model repos- 
itories? 

2. Should one PML be used to support each meta-process phase or should we have 
many PMLs, each devoted to a different meta-phase? Advantages and disadvantages 
stem from those in their respective domain. If the same language is used across dif- 
ferent phases, then it easier to keep the different models consistent and to reuse 
knowledge across the different phases. On the other hand, it is evident that a single 
language is seldom sufficient to support the whole life cycle of a deliverable, from 
its conception to its implementation and operation. 

A general software architecture for a PML comprises at least (see Chapter 5): a repos- 
itory in which the model is stored and maintained in a versioned fashion; an interpreter 
to execute models; an editor to facilitate model creation and manipulation. The PML 
design choices influence the architectural choices, e.g., there can be several incompati- 
ble PMLs, where each must be provided with its own interpreter and editor, or there can 
be several compatible PMLs in the sense that they can be executed by the same inter- 
preter. This will be discussed. 

There are obviously results from current research and technology that have the poten- 
tial to be adapted for the process modelling domain, and we will therefore look at 
related areas, such as information modelling, databases and groupware for ideas and 
suitable solutions. 

This chapter is structured as follows: Section 3.2 presents some requirements for 
PMLs. This includes both the software process elements and the process modelling 
phases that have to be described by a PML. It discusses views connected to process 
roles and meta-process roles such as those of project managers, process engineers, proc- 
ess agents etc. It also deals with general modelling demands, such as understandability 
and modularization. Section 3.3 introduces the theoretical background for PMLs, by 
identifying the main conceptual sources and linguistic solutions for existing PMLs. 
Section 3.4 and Section 3.5 give a summary of some existing PMLs, and classify these 
with respect to linguistic paradigms and the nature of the support offered. Conclusions 
and directions for future research are offered in Section 3.7. 



3.2 Requirements on Process Modelling Languages 

A software process model is a representation of the real-world activities of a software 
production process. A software process model is developed, analysed, refined, trans- 
formed and/or enacted within the meta-process. Thus, any software process model has 
to model the real-world process appropriately and it has to meet the specific require- 
ments of each phase of the meta-process. These imply requirements for the process 
modelling language by which a process model is defined. These requirements on the 




3.2 Requirements on Process Modelling Languages 29 



process model and on the corresponding process modelling languages are discussed and 
explained within this section, which is organised according to the following questions: 

1 . What has to be defined within a process model? What are the constituents of a soft- 
ware process and how are they interrelated? 

2. What are the PML requirements and what are their relationships with each phase of 
the meta-process and respective meta-process users? 



3.2.1 Process Elements 

A model of a real-world situation consists of a description of the structure and behav- 
iour of all problem-relevant constituents as well as of their static and dynamic interre- 
lationships. For a given problem area, we can classify the general constituents and their 
relationships into constituent and relationship types, and a concrete process model con- 
sists of instances of these types. 

A software process consists of concurrent, cooperating activities, encompassing soft- 
ware development and maintenance activities as well as those of project management 
and quality assurance. Early classifications of the constituents of process models can be 
found in [Conr92, Lonc93, Feil93, Conr94c], which identify the following basic (or pri- 
mary) constituent types. There are six primary process elements, five of which have 
already been introduced in Chapter 1, Figure 1.4: 

1 . Activity: A concurrent process step, operating on software artifacts and coupled to a 
human agent or performer and to external production tool(s). It includes communi- 
cation channels and control directives. It can be at different abstraction levels, i.e. 
activities can be decomposed. Concurrent and cooperating activities, some determin- 
istic and others non-deterministic, are the heart of any process. These include soft- 
ware development and maintenance activities, project management and quality 
assurance activities, and meta-process activities. They can be at almost any level of 
granularity, and are usually associated with roles that can be undertaken by certain 
categories of users and/or tools. Artifacts constitute the operands (inputs/outputs) of 
activities, so the core PML must contain a Data Manipulation Language (DML) to 
facilitate their access. 

2. Product: This is a software artifact which is persistent and versioned, and which can 
be simple or composite with mutual relationships. The artifacts describe the product 
in question: software products and their composites, and associated documents such 
as design documents, user documentation and test data. In a reflective system, all 
process model fragments can themselves be considered to be artifacts, i.e. including 
“meta-data” such as quality manuals and process models. The product model will 
usually contain a basic data model, a product schema, and instances of the latter. The 
description of a product must be comprised of, as a minimum, its composition and 
dependencies. 

3. Role: A role describes the rights and responsibilities of the human who will be in 
charge of a human agent. 
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4. Human: Humans are process agents or process performers who may be organised 
into teams. A role, referred to above, can be undertaken by humans with the appro- 
priate skills and authority. A single human user or process agent can fulfil a set of 
roles. They can also be a member of several teams or groups (which themselves can 
possibly nested) representing either project teams or line organizations. 

5. Tool for software production: Tool details are represented in the tool- view referred 
to below. The tool model must specify how tools can be accessed and controlled. We 
must distinguish between batch and interactive tools, and be able to handle call- 
backs from both. Batch tools cover compilers, links, and parsers etc. while interac- 
tive tools span from textual editors to graphic CASE tools. 

6. Evolution Support: General meta-process support for static or dynamic variability 
of the process model. It follows from the human-oriented nature of the software proc- 
ess that we have an inherent cause of evolution during process enactment. This 
means that most previous lifecycle phases must be repeatable “on-the-fly”. As a con- 
sequence of this, the core PML must offer support for evolution of at least the process 
model, both technically (e.g. by reflection or interpretation) and conceptually (by a 
defined meta-model). 

The secondary process elements are: 

7. Project/Organisation: Organizations consist of humans who have relationships with 
one another and to other process elements. A project is a temporary organization 
structure set up to achieve a specific objective. Business rules and expressible goals, 
as identified for the “Direction” in Figure 1 .4 must be described in this concept. A 
project contains a variety of domain-specific information, so a project model might 
include a workplan with sub-activities or sub-projects, identify those responsible for 
activities, the overall goals, inputs and outputs, available resources, time estimates, 
work records (time sheets, logs etc.), quality model (see item 12), cooperation pat- 
terns between projects, and connection to workspace transactions and versioning 
(see item 11). Such project information is revised almost daily both to record ongo- 
ing work and as a basis for making adjustments. 

8. Work Context: A workspace (WS) containing and controlling artifacts for the actual 
(sub)process. These artifacts are often represented as files which are checked out 
from a repository. It includes a production workspace and available production tools. 
A production workspace (e.g. files or a CASE-tool repository) is the external rep- 
resentation of a configuration, which again is a requested part of the total, versioned 
product. 

9. User-view: This is a general interface to help the user comprehend and guide the 
(enacting) process model. The external model representation may be different to the 
internal one. The problem of displaying complex and heterogeneous information to 
users with different levels of competence and goals are shared by most computerised 
systems [Myer89]. The general paradigm of user interfaces is that we should split 
how it works (internal model, e.g. in C or Prolog) from how to do it (external view). 
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Some aspects to consider are: uniformity of presentation and interaction, easy com- 
prehension of presented information, and flexible choice of presentation formats (fil- 
ters, viewers). 

10. Cooperation Model: Cooperation protocols, such as sharing or locking, need to be 
described. There are two basic modes of cooperation: sequential, e.g. by normal 
work or review chains, or parallel, e.g. based upon workspace overlap. The cooper- 
ation model must include communication protocols of or on objects and coordination 
of actions (ordering and synchronisation). At a higher level of abstraction, it may 
include goal sharing and sophisticated interaction protocols such as negotiation in 
situations of conflict. 

11. Versioning/Transaction model: Versioning at least of the production workspace 
is needed as well as some support for long transactions. The transaction model 
should be nested and ought to allow pre-commit cooperation. 

12. Quality/Performance Model: This is the overall quality model of product and/or 
process. A product quality model includes operational goals of product quality and 
associated metrics, e.g. review and test status [Naka90]. The process performance 
model for process quality expresses compliance to the stated process model, e.g. 
with respect to deadlines, budget, and user roles. 

A process model consists of instances of these process elements together with addi- 
tional constraints controlling how they may be interrelated. Those interrelationship 
types are implicitly mentioned above, e.g., an activity has_input artifacts or agents play 
a role (see Figure 1.4). 

These basic elements and relationships allow coarse-grained modelling of a software 
process. A software process modelling language has to provide language features to 
model these basic and advanced constituents (or sub-models) as well as their interrela- 
tionships. There are many ways to support the modelling of these process model ingre- 
dients by means of a PML. PMLs can be classified according to certain characteristics 
which will be described shortly. Some desired characteristics are in conflict and so it is 
not possible to address all characteristics within one specification language at the same 
depth, and the PML designer has frequently to make trade-offs between characteristics 
in any particular PML. This choice is closely related to the answers to Question 2 posed 
on page 28 and it will be discussed later. 

3.2.2 PML Requirements and Meta-process Phases 

A process model is used in different ways by different roles during the different phases 
of the meta-process. Here we will indicate the main phases of the software development 
meta-process together with their specific requirements. 

MP-1. Process elicitation and requirement specifications. During this phase, the 
process owner needs to set overall goals, and to understand the ramifications of 
addressing these by means of an abstract process model. In this phase we must assist 
and support human understanding and negotiation of the perceived as-is process. We 
will need overall (conceptual) modelling, often stating business rules, coarse-grained 
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work flow, and indicating general work responsibilities. Intuitive and often graphical 
notations may be important if the users of this model are company decision makers. 
The PML of this phase will resemble languages used for Information Systems and 
Enterprise Modelling. 

MP-2. Process Analysis. Here, the PML must be sufficiently formal to be used for rea- 
soning or simulation. Changed needs from markets and new inputs from technology 
providers may be addressed in this phase. Decisions on the changes needed to define 
a new to-be process will typically take place during this phase, so quality and per- 
formance matters must also be dealt with. Process analysts have to provide an 
understandable, consistent, and verifiable model of the proposed organisation pro- 
duction process. 

MP-3. Process Design. Here, the PML must be able to express a more detailed process 
architecture and to incorporate more project-specific information such as the number 
of workpackages or sub-projects, overall planning (dependencies, timing), develop- 
ment technology (00 techniques), and quality model. Process designers need to 
describe how the process model will be supported by means of the PSEE. The proc- 
ess analyst and designer role is often merged into that of a process engineer. 

MP-4. Process Implementation. In this phase, the PML must allow the specification 
of sufficient low-level details to allow the model to be enacted. This model contains 
information that can be compared to that contained in a project management plan 
such as task start and finish dates, allocated resources, etc. This model must possibly 
be translated or otherwise prepared for execution. Process model programmers 
have to code the these decisions in an executable PML 

MP-5. Process Enactment The enacting process model, residing in the PSEE reposi- 
tory, is interpreted by a process engine. This process engine also interacts with pro- 
duction tools and with process agent through a tool interface (e.g. a Broadcast 
Message Server BMS) and a user interface (e.g. through an agenda) respectively. 
Process agents need a somewhat similar view, though customised to their specific 
roles. Eor example Project managers need a project management view, because 
they need to understand, plan, and control project structure, project resources, and 
work progress. 

MP-6. Process Assessment of quality and performance. This covers a wide range of 
activity, from trivial follow-up of tool activations to collecting prepared performance 
and quality measurements. All such data can be provided as feedback to previous 
phases, either to guide the process or possibly to evolve the process model and its 
process. This phase ought to be regulated by a Quality and Performance model, and 
production tools need to be properly instmmented for this purpose. 

Having identified the discrete phases of the software development meta-process, we 

recall the well-known characteristics of any programming language which are: 
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• Formality. The syntax and semantics of a PML may be defined formally, i.e. pre- 
cisely, or informally, i.e. intuitively. Formal PMLs support, for example, the reason- 
ing about developed models, the analysing of the precisely defined properties of a 
model, or the transforming of models in a consistent manner. 

• Expressiveness. This feature of a PML indicates whether all aspects of a process 

model (i.e. all process elements), may be directly modelled by language features of 
the PML or have, for example, to be expressed by means of additional comments. 

• Understandability. This is dependent on the possible users of the process model. 

Users with a computer science background will find understanding in a model writ- 
ten in a PML that resembles a programming language. Those with other backgrounds 
will prefer graphic representations based on familiar metaphors. 

• The PML may offer modelling-in-the-large concepts, such as abstraction and mod- 
ularization, to structure a process model into submodels connected by certain rela- 
tionships. Abstraction concepts may support the definition of more general, abstract 
submodels which are customised within a concrete process model. In addition, a 
PML may offer the possibility of distinguishing between generic (template) and spe- 
cific (instantiated) process models. 

• Executability; The PML may support the defining of operational models. Opera- 
tional models are executable and easily enactable. 

• Analysability; The PML may support the defining of descriptive models, e.g. pred- 

icate logic expressions. Descriptive models are easily analysable. 

• The PML may directly support the evolution of process models. Reflection is one 

important requirement. In this case there are parameterization, dynamic binding, per- 
sistency and versioning issues to be addressed. 



Table 3.1 Requirements for meta-process phases 
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• Multiple conceptual perspectives/views: The PML may support the definition of 
(consistent) views of certain perspectives of a process model. This implies mecha- 
nisms to integrate different views of a process model into a common, overall process 
model. 

The properties of the meta-process phases and the properties of programming lan- 
guages are brought together in Table 3.1 which shows, for each meta-process phase, 
which PML characteristics are either needed for the meta-process activities, or assist 
them, or in fact hinder them. 



3.3 Possible PML Technologies from Other Languages/Domains 

As previously mentioned, process modelling is an extensive and complex domain. 
There has been much discussion about the “right” PML, and we must consider both 
technical and non-technical issues. 

Process Modelling languages have their roots in computer science and related 
domains, and the main sources and associated approaches can be characterised. There 
follows a list of these characteristic approaches together with a brief explanation. The 
relationships between these technologies and the process elements is summarised in 
Table 3.2. After this characterization we will discuss in Section 3.3.8 the issue of “one 
or many PMLs?”. 



3.3.1 Project Management 

Bar charts and activity networks are graphical notations used in project management. 
Activity bar charts describe a project in terms of its activities, together with their antic- 
ipated durations and start dates. Activity networks show activity inter-dependencies. 
According to [Liu89], activity networks can be generated by PML descriptions. Staff 
allocation charts describe the binding between responsible staff and activities. The 
Process Weaver PSEE has been coupled to Microsoft Project, a commercial project 
management tool. This allows the use of common project management techniques to 
perform, for example, critical path analysis. PSEEs such as CADES, ISTAR and the 
Virtual Design Team, can be considered as having been inspired by the project manage- 
ment. 



3.3.2 Formal Specification Languages 

A formal specification language is a language whose syntax and semantics are formally 
defined. A formal specification is a mathematical object that can be analysed using 
mathematical methods. Many PMLs are based on Petri nets. In [Gree92] the specifica- 
tion language CSP [Hoar85] is investigated as a basis for a PML and in [Naka90] the 
specification language OBJ is exploited. Specification languages fall into categories 
such as model oriented or property oriented, whether or not they are concurrent, or 
whether or not they are modular. 
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Mathematical methods for process modelling are still lacking and so we believe that 
PML research must exploit as far as possible results from the specification language 
community. 



3.3.3 Informal Design Notations 

Design notations such as object oriented design notations are usually less formally 
defined than specification languages. In the PM domain, Data Flow Diagrams are the 
basis for IDEFO, and Statemate is the basis for EPM [Hump89]. In E3, the basis of the 
PML is an object oriented design notation. Here we can distinguish between three kinds 
of notations: those devoted to static descriptions, e.g. ER; behavioural descriptions, e.g. 
state transition diagrams; and those devoted to functional description, e.g. data flow dia- 
grams. 



3.3.4 Programming Languages 

As a first reaction to the assertion “Software processes are software too”, existing pro- 
gramming languages such as ADA in APPL/A, have been exploited as PML kernels. 
They have been crucial for first PM experiments, even if they suffer the granularity 
problems, e.g., language first order objects are low level, such as integers and real. 



3.3.5 Database Languages 

Almost every PML is integrated with an underlying database to store products. Active 
databases may assist in representing tool effects such as triggers, so data modelling is a 
part of the process modelling activity and some PML include a data base description 
language. This is the case in ADELE, ALE, and PEACE for instance. 



3.3.6 CASE Tools and Tool Integration Mechanisms 

Some PMLs delegate tool description and integration to an external engine, e.g. 
SPADE, which is based on the PML SLANG, uses DecFuse to describe and to integrate 
tools. 



3.3.7 WorkFlow and Groupware 

The WorkElow and Groupware communities are addressing problems that partially 
overlap those addressed by the PM community. However, no PM language is based on 
or integrated with WorkFlow or Groupware tools. The opposite is also untrue, i.e., none 
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of the PMLs reviewed in this chapter have been exploited as a basis for WorkFlow or 
Groupware tools. 



Table 3.2 Technology among process elements coverage 
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Table 3.2 maps the extent to which these existing PML technologies can support the 
process elements, using the same notation as before. 



3.3.8 The PML Design Dilemma: One or Many PMLs? 

A lot of effort has been expended during the recent years to characterise what could be 
an “ideal” PML. The process modelling community has expressed severe requirements 
for such a PML: it must comprehensibly and understandably express the primary proc- 
ess elements, e.g. activities, products etc. (Section 3.2.1); it must allow the expression 
of enactable and enacting process models, where the two former may be either com- 
pany-generic or project-specific; and it must offer facilities for structuring, modulariza- 
tion, customizing, and evolution of the same [Perr89]. 

The different and partly conflicting demands on the underlying PML can be formu- 
lated, depending on the purpose of the process model, for example to provide human 
understanding vs. static analysis as opposed to dynamic enactment of process models. 
Thus fundamentally different PMLs and PML notations may be needed to cover such a 
diversity in scope, coverage, abstraction, granularity, customization, and user views 
[Conr95, Ambr94]. 



There are at least four approaches LI — L4 for PML design: 
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•LI. One large fixed core PML whose primitives cover all relevant basic process ele- 
ments, such as activities and evolution support. Such PMLs usually include “hard 
coded” primitives for concurrent activities; 

• L2. One extensible and smaller core PML. The primitives allow declarative constructs 

and include “soft” primitives, such as extensible types; 

• L3. One core and several compatible sub-PMLs. These are high-level sub-PMLs (see 

for example, APEL or Statecharts) that can be down-translatable to a core PML or to 
alternatives of same; 

• L4. One core and several incompatible sub-PMLs. The other sub-PMLs are outside 

and not translatable to a core PML. Examples include languages to express cooper- 
ation, versioning and transactions, and quality models. This implies that non-homo- 
geneous and partial process models and tools may co-exist. 

PMLs that reflect different and diverse linguistic paradigms, e.g. rule- 
based [Shau93], Petri nets [Band94], and imperative [Kadi92], have been presented in 
literature. However no PML has been demonstrated to satisfy all the PM requirements, 
and neither does a real assessment of current PMLs exist. The best that has been 
achieved so far has been the comparison of 18 process modelling languages undertaken 
in during ISPW6, each of them being used to describe the ISPW6 process example. 

The chosen strategy for PML design will influence the size and complexity of the 
PML and the resulting PSEE. A good language design assumes that we understand the 
domain, so that we can make sensible decisions about which process elements should 
be covered, where and how. If our knowledge is poor or immature, we might initially 
experiment with a small core PML and many sub-PMLs. After collecting experiences, 
we would be in a better position to decide - both strategically and technically - on the 
mutual sub-PML interfaces, which sub-PMLs could be reconciled, or which could be 
merged into the core PML. There is clear analogy with conceptual modelling of soft- 
ware systems: in newer approaches (see for example [Hee92]), entity-relationship or 
object-oriented data models have been effectively combined with data flow diagrams or 
Petri-nets to describe the static and dynamic parts of the domain, respectively. Analo- 
gous work has also been carried out in the area of federated databases seeking to unify 
different data models, schemes and instances from possibly heterogeneous sub-data- 
bases. 

So, what is the core PML and what are the non-core PMLs, and how are all these 
related? This means that we should think strategically to prepare for the co-existence of 
possibly non-homogeneous and partial process models. We may even stay with a small 
core PML to reduce labour and risk, and enlarge as insight and confidence is gained - 
as for instance the way that product modelling is dealt with by the use of minimal place- 
holders in Process Weaver. 

In other words, there are many factors to consider when specifying and assessing the 
functionality of a PML to describe a given or desired process. Sometimes we do not 
have a free design choice, since parts of the PM domain are already covered by existing 
or standardised “PMLs” and associated tools, but these may possibly not be mutually 




38 3 Process Modelling Languages 



homogeneous. We can mention project models, data descriptions used by CASE tools, 
tool configuration schemes in broadcast message servers, and issues related to user 
interfaces or configuration management. Thus, PML interoperability and standardi- 
zation becomes a crucial issue, and reference can be made to federated databases 
[Shet93] and standardization work at the International Workflow Management Coali- 
tion [Mars93] and OMG [Grou92]. 

It is worth mentioning ongoing standardization efforts, such as Process Interchange 
Format (PIF) and the Unified Modelling Language (UML) [Part97]. PIF provides 
standard entities (Activity, Decision, Object, Agent, TimePoint) and relations (Creates, 
Modifies, Performs, Uses, Before, Successor, Activity-Status). UML covers a spectrum 
of modelling tasks, from 00 product models to enterprise models. It offers stereotypes 
or meta-types (Event, Exception, Metaclass, Utility), static structure diagrams (class 
and object diagrams), use case diagrams (stimuli-response), sequence diagrams, collab- 
oration schemas, role diagrams, state diagrams; activity diagrams, and implementation 
diagrams. 

There follows a survey of some PMLs. Section 3.4 describes PMLs developed by 
workers participating to Promoter project and Section 3.5 refers to three other promi- 
nent PMLs. 



3.4 Process Modelling Languages in the Promoter Context 



3.4.1 The Survey Method 

The purposes of this survey are twofold: to provide examples upon which to consider 
the PML issues identified earlier in this chapter, and to summarise the main features of 
existing PMLs. It was undertaken by: 1) a study of background material; 2) the produc- 
tion of a PML classification; 3) the distribution of this classification to PML designers; 
4) feedback from PML designers; and 5) the subsequent adaptation of the PML classi- 
fication. 

To make this process feasible, it was decided to provide a classification of the Euro- 
pean PMLs developed by the partners of the Promoter project. The reasons for this 
choice are: 1) there does exist background material that has already been classified and 
assessed in the work of J. Lonchamp in the first Promoter book [Lonc94a]; 2) commu- 
nication with the designers of these PMLs is facilitated by the Promoter network. Non- 
European PMLs are not neglected, and an appendix is dedicated to them. 

The grid for this classification is derived from the issues discussed previously in this 
chapter. For each PML, we will try to answer the following questions: a) what is the 
PML design paradigm? b) which meta-process phases is the PML addressing? c) which 
process elements can be described? d) what are the technical requirements that are ful- 
filled by the PML? e) by which domains or technologies has the PML has been influ- 
enced? 
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The PMLs are presented without references since they are all described (in exactly 
the same order) in the first Promoter book [Fink94], Table 3.3 will summarise PML fea- 
tures by assessing which process element is modelled and by which sub-language Table 
3.4 summarises the discussion about PML features and meta-phase support. 

3.4.2 EPOS SPELL 

EPOS was one of the first attempts in at merging different paradigms. EPOS SPELL, 
that is the EPOS PML, consists of an extensible kernel of pre-defined entity and relation 
types (task, data, tool, and role) that can be specialised by inheritance. The Task type 
declares PRE- and POST- conditions that are first order logic expressions (as in 
AI): FORMAL that are input output parameters declaration (as in data flow diagrams) 
and DECOMPOSITION that defines task breakdown (as in functional decomposition). 
SPELL is implemented on top of an object oriented database that provides support for 
persistence, versioning, and transactions. It is a reflexive language that provides support 
for both evolution and the explicit definition of a meta-process. 

SPELL, which has its roots in object oriented languages and databases, reflective sys- 
tems, AI planning, and data flow systems, has SPELL types that can be defined by a 
textual Prolog-based notation that is suitable for implementation, but not for the higher 
level phases such as elicitation. SPELL instances can be visualised in a graphic envi- 
ronment that gives support for process assessment. 

3.4.3 SOCCA 

SOCCA is a specification language that offers a class diagram for the data perspective, 
state transition diagrams for the behaviour perspective, PARADIGM for the communi- 
cation, and an object flow diagram for the input-output or process perspective. There is 
no core language, rather several PMLs. 

SOCCA has been clearly influenced by information system modelling, and is related 
to OMT [Rumb91] which it extends by explicitly addressing communication. 

The main purposes of modelling are declared to be model analysis and expression for 
humans. The PML in its current version mainly concentrates on the first meta-process 
phases, i.e. requirement specification, analysis and design, and on assessment. Iteration 
of these phases also is allowed, e.g. redesign after assessment, particularly in case of 
change. In future more support for implementation and enaction are envisaged. 

Each process element in a process model appears in a class diagram and is associated 
with attributes and methods. Process elements, i.e. classes, are connected to each other 
by relations. Eor each class, the interface (external behaviour) and implementation 
(internal behaviour) are specified by state transition diagrams (STD). Consistency 
between the classes and the STDs is assured by labelling transitions from external STDs 
with methods from the corresponding class. Communication between the STDs is mod- 
elled through PARADIGM. Further integration of the data and behaviour perspectives 
is achieved by describing the effect of a transition in terms of insertion, update, and 
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deletion of class and relations instances. No specific language support is given to the 
modelling of different process artifacts, i.e., even the primary process elements (e.g., 
activity, artifacts, humans and roles, tools, and support for meta-process) have not been 
provided with special syntactic or semantics support. 

SOCCA diagrammatic notations help in understanding process models. Although a 
SOCCA model is not truly enactable, support has been provided for simulation. It is the 
STD sub-PML, in combination with PARADIGM, which guides interpretation. The 
support for analysability relies on simulation. Different views, static and behavioural, 
are offered. Abstraction and modularization derives from object-oriented principles 
such as classification and aggregation, however these have not been tailored to process 
modelling. No specific support is yet devoted to customization and evolution. 

3.4.4 Merlin 

In Merlin, process modelling is performed on two different levels. The first level is vis- 
ible to the process-engineer and is represented by the process-design language 
ESCAPE. The second level is used for enacting the process design and represented by 
the Prolog-like process programming language. 

The process-design language ESCAPE (Extended Entity Relationship Models and 
Statecharts Combined for Advanced Process Engineering) has its roots in information 
system modelling. It is a graphical language which distinguishes between three differ- 
ent models: (1) the object-model, (2) the coordination-model and (3) the organization- 
model. The object-model is based on the EER-model and used to specify the structural 
aspects of the process, e.g. the document-types, the activities, the relationships. The 
coordination-model is based on Statecharts and is used to specify the behavioural 
aspects of the process, e.g. the pre- and post- conditions for activities, and the change 
conditions for state changes. The organizational-model is based on tables and used to 
specify the organizational aspects of a process, such as roles and responsibilities. 

ESCAPE designs are understandable and, because the concepts used are well known 
from information system modelling (e.g. OMT), the structuring of processes is reached 
through a separation of concerns for basic concepts. For example, transaction manage- 
ment can be presumed and must not be part of the process model itself. A further advan- 
tage of ESCAPE is that an application-specific analysis is supported. The process 
design is checked for errors, warnings and optimizations, so that process model quality 
can be improved before enactment. 

Process enactment is reached by automatically mapping the ESCAPE design to the 
enactable Prolog-like process programming language. The ESCAPE-definition is 
mapped to PROLOG-facts. PROLOG-rules specify the semantics, i.e.how the afore- 
mentioned facts are interpreted. This includes defining how the information to build the 
working context is selected, how transaction management is supported, how version 
management is handled etc. Process- and project level are variable for every process 
specified whilst the rules (also called the cooperation-model), are the invariant part of 
the process program. There is currently no support for simulation. 
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3.4.5 OIKOS 

OIKOS offers two PMLs, LIMBO and Pate. LIMBO is the specification language to be 
used during high level meta-process phases such as specification and design. Pate is an 
executable distributed language. The meta-process is based on step-wise refinement of 
the LIMBO specification into Pate executable code. 

Both languages are based on concurrent logic derived from Extended Shared Prolog 
(EXP). The distinguishing features of an OIKOS process model are the blackboard pat- 
tern of communication among concurrent agents. Activities are arranged in a hierarchy 
that provides the main abstraction/modularization axis. 

No specific language support is provided for tool and data description. Tools and data 
reside in external repositories and are specified by a signature. 

The graphical notation for LIMBO is supported by an editor and browser. Analysis is 
supported only insofar as it is possible to animate a specification, i.e. run it in a simu- 
lated environment, without actual tools and documents. 



3.4.6 ALF 

ALE has its roots in ER data Modelling, active databases, and logic programming. A 
generic process model in ALF consists of fragments, called MASPs (Model for 
Assisted Software Process). The ALF PML comprises an Extended Entity Relationship 
Attribute (ERA) data model to describe the data part; an operator type sub-language for 
tool description; a rule sub-language to express in an event-condition-action fashion 
(how certain events have to be processed); a constraint sub-language to define, by 
means of path expressions, operator invocation order; and a first order logic language 
to define “characteristics”, that is an expression which has to be true and is used as 
invariant or objective. 

The language consists of these five compatible sub-languages, of whom the core is 
the logical re-formulation of the extended entity relationship data model. MASPs can 
be arranged in hierarchies where an operator type is itself a MASP. Import/Export 
mechanisms between MASPs are provided. Static evolution is facilitated by the MASP 
modularization facilities, dynamic evolution can be done either during instantiation (by 
parameterization) or after, during execution, by instance modification. 

A generic model can be instantiated into a project-specific enactable model, referred 
to as the IMASP. This is done either statically or dynamically. ALF PML is not specific 
to the meta-process phase, but it should be suitable for incremental development, from 
specification to implementation, due to its good specialization mechanisms. The lan- 
guage is provided with operational semantics, and some rules and mechanisms are pro- 
vided to detect inconsistencies and possible inconsistencies in a MASP specification 
(Inconsistency Tracker For MASPs assistance). 
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3.4.7 ADELE-TEMPO 

Adele has its roots in object-oriented languages, database Modelling, and trigger mech- 
anisms, and offers two PMLs. The original language is an object oriented database lan- 
guage extended with relationships and triggers. Documents, tools, and work contexts 
are the primary elements of this enactable language. Activities can be expressed by 
means of triggers that are condition/action rules associated with data base operations. 
The first language has been evaluated as being effective for process implementation and 
enaction, but not for specification and assessment as the formalism is difficult for 
humans to understand, and trigger execution is difficult to control and monitor. To over- 
come these limitations, the process formalism Tempo has been designed to offer sup- 
port for the modelling of primary process elements. TEMPO is based on the notions of 
role (defining both static and dynamic object properties) and connection (expressing 
how objects collaborate). Special emphasis is given to cooperation, versioning, and 
configuration management modelling. 

Later, in the framework of the PERFECT Esprit project, the APEL (Abstract Process 
Engine Language) language was developed. APEL is a graphical high level language, 
designed both for process capture and understanding and for its enaction. It can be com- 
piled toward an abstract Process Engine built from two commercial basic process 
engines which interoperate on a peer to peer basis: Adele and Process Weaver. In APEL 
a process is represented using the following different aspects: Control flow, data flow, 
data description (OMT like). Work Space and cooperation, (user) roles, and state tran- 
sition diagram. 

Aspects are interrelated and consistency is enforced, but there is no main aspect. 
Users can describe the process using all the aspects, or a subset of them. Each descrip- 
tion is an abstraction level. Each level can be recursively refined. 

3.4.8 SPADE 

The SPADE PML is referred to as SLANG. It consists of two layered languages: kernel 
SLANG that is a formal language based on Petri nets (for behaviour definition) and 
object orientation (for static structure definition); and full SLANG that enriches kernel 
SLANG with PM-specific syntactic sugar and with special types for process modelling 
evolution. SLANG is integrated with the 02 object oriented data base which acts as a 
repository for both process model and process products. 

In addition, it is possible to model cooperation policies as part of the process model. 
This is achieved through process-tool interaction mechanisms embedded in special lan- 
guage constructs (black transitions and user places). Tools can be integrated directly in 
the SPADE environment or via commercial tool integration products, such as DEC 
FUSE and SUN ToolTalk. 

SLANG, being reflective, should be suitable for modelling and enacting all meta- 
processes phases as Petri nets are an analysis and simulation tool and the language is 
enactable. 
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3.4.9 PEACE+ 

PEACE+ is the second phase of PEACE [Arba94], It enhances PEACE with (1) a coop- 
eration formalism and support that allows the description and enaction of interaction 
models (communication, coordination, negotiation, etc.) during the enaction of distrib- 
uted process models [Allo94a, Allo94a]; (2) a process model enactment and evolution 
system based on stmctural and operational reflection and reification [Mins91, Latr93]. 
PEACE-h/PML is an enactable knowledge representation modelling formalism based 
on the multi-agent paradigm of the field of Distributed Artificial Intelligence. The coop- 
eration aspects rely on an intentional approach of rational action [Allo95]. A software 
process is seen as a multi-agent system where agents that are cognitive, rational and 
intentional assist users in enacting process model tasks. 

PEACE-h/PML is derived from the ALE PML, and consists of two compatible sub- 
languages; the data definition language of the PCTE/OMS to represent the object model 
and the PME/DL (process model element description language) to represent the activity 
model. Process model elements are defined in terms of user performer roles, process 
model tasks and process model agents. 

User performer roles define the roles which members of a project may play. They are 
described in terms of a role’s view on the process object base, its privileges, its obliga- 
tions and the required qualifications of the performers which are allowed to be con- 
nected to the role (their position, skill, experience, etc.). 

A process model task is defined by input/output typed parameters (expressed in the 
PCTE/OMS DDL), a precondition i.e. a necessary condition for starting its enactment, 
and finally the goal that should be satisfied by the executing agents of the task, the role 
a performer must have to enact the task and the kind of interaction with this latter (inter- 
active, non interactive). 

A process model agent is defined by its knowledge of objects and tasks in the soft- 
ware process, its capabilities in terms of operators on process tasks and objects, its inter- 
action capabilities in terms of acquaintances and interaction models, and its goal. A 
process model agent acquaintance defines the other agents it is aware of and with whom 
it can interact (communicate, coordinate and cooperate) using interaction models. Each 
interaction model is defined by a set of states and a set of transitions. A transition is 
effected through the realisation of a communication act which may be a request, a noti- 
fication, a command, etc. 

Knowledge, preconditions, postconditions and goals are expressed using basic oper- 
ators of belief, intention, necessity and possibility of a multimodal logic. This consti- 
tutes a good experiment in applying formal techniques to process modelling. The 
advantage of using multimodal logic is that it allows nonmonotonic reasoning which 
helps to support the process dynamics and evolution that result from the existence of 
incomplete and uncertain knowledge during the process enactment [Arba94]. PEACEh-/ 
PML is a reflective language, and allows users to define, enact and evolve both the soft- 
ware processes and meta-processes in a uniform manner. 
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An associated graphic language called Process Description Diagram (PDD), designed 
for process understanding and design, has been developed in the Esprit SCALE project. 
This language permits the generation of PML definitions [Basi93, Oque95]. 

3.4.10 E3 

E3 [Jacc99] offers an object oriented analysis and design notation that is suitable for the 
meta-process high-level phases and is not enactable. E3 PML offers pre-defined classes 
and associations which are provided with intuitive graphic symbols. User defined 
classes and user defined associations inherit graphic symbols from their respective 
super classes and super associations. Attributes and methods can be defined for classes 
and associations (implementation meta-phase). 

For the E3 PML, a drawing tool has been developed that facilitates the definition, 
browsing, and reusing of process model fragments according to four views. These are; 
the inheritance view (IV); task view (TV); functional decomposition (TDV); and infor- 
mational perspective(UV). The tool implements syntactic and static semantics checks 
on process models thus facilitating the analysis meta-phase. The sole goal of the E3 
PML design is that of providing easy support for process model definition. 

3.4.11 PADM 

The Process Analysis and Design Methodology (PADM) is an example of adding a 
specification language on top of an existing system. Its exemplar enactment system is 
the ICL product ProcessWise Integrator (PWI), formerly IPSE 2.5, which coordinates 
users and tools by enacting a process written in its PML. PWI PML is class-based, pro- 
viding base classes and reflexive features covering the primary process elements: 
Action, Entity, Role, Interaction, User Agent, Tool Agent, GetClassDefinition and 
BehaveAs. PWI PML has the ability to reuse class by specialization. The powerful 
change mechanism means that meta-process phases can be supported when they repre- 
sented as a network of roles and interactions. 

Experience with PWI PML showed that the detail needed for enactment made it dif- 
ficult to use for model elicitation or investigating design alternatives. An effective 
enactment language needed at least one design method to exploit it. 

Base Model (BM) provides a specification language which supports the gradual 
refinement of a detailed design from a high-level specification. Its underlying temporal 
logic semantics can be exploited not only to prove properties of models, but also to 
prove the correctness of the refinements. BM therefore concentrates on the specifica- 
tion, analysis and design meta-process stages. BM does not deal directly with process 
elements but with the abstract concepts of objects and operations. This enables the mod- 
eller to focus on one aspect of the model during the initial development stage and then 
add further details. 

BM and PWI PML are two compatible languages, as it would be possible to formally 
refine from the most detailed BM model into PWI PML, but currently some hand trans- 
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lation is needed. The BM stepper can be used to assist checking the consistency of the 
BM and PML. The BM-PWI PML combination means that each language can exploit 
its strengths. BM provides a formal development process. PWI PML deals with the 
enactment details such as the interface between enactment engine and tools, and the 
incremental change of process instances. 

BM is influenced by its underlying temporal logic semantics, and formal specifica- 
tion approaches in general. PWI PML is influenced by object-oriented languages, 
reflexive systems, and role-interaction theory. 

Within PADM there has also been work on Conceptual Models, an alternative to BM 
for modellers who prefer informality in the early stages. PWI has been integrated with 
a web server (referred to as ProcessWeb [Warb99]) to utilise web browser as a user 
interface to the process engine. This effectively separates the concerns of the process 
model from those of the user interface. 



3.4.12 Discussion 

In Table 3.3, we endeavour to present a taxonomy of how (and if) the different PMLs 
can represent the different process elements which have already been introduced, and 
we also attempt to classify each PML according to its design approach. Note that some 
PMLs (those based on multiple paradigms) have been classified under more than one 
design approach It is followed by Table 3.4 which gives, for each PML, an indication 
of how, and if, each meta-process phase is supported. 
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Table 3.4 Meta-process phase and existing PMLs 
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3.5 Other PMLs 

In this section we provide a survey of three PMLs developed outside Promoter. They 
are the APPL/A PML used in both the pioneering research PSEEs ARCADIA and 
MARVEL PMLs, and the Process Weaver PML from a pioneering commercial system. 
These three PMLs are representative of the three main linguistic paradigms, respec- 
tively procedural (APPL/A), rule based (Marvel), and Petri net based (Process Weaver). 

3.5.1 APPL/A 

APPL/A has been developed in the context of the ARCADIA project and it is a process 
programming language. APPL/A is a superset of Ada, extended with persistency, rela- 
tion management, transactions, and triggers. The language is thus mainly procedural, 
but consistency constraints can be expressed as predicates on relationships. In the fol- 
lowing we give an excerpt of a process program coded in APPL/A taken from [Sutt93]: 

( 1 ) Procedure SingleUserModel is... 

( 2 ) Begin 
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(3) while not Done loop 

(4) case CurrentApproach is 

(5) when TopDown => 

(6) if NeedRool then CreateRoot; 

(7) elsif NeedChildren then 

(8) SelectNodeToElaborate(currentNode);CreateChil- 
dren(CurrentN ode) ; 

(9) else SelectNodeToEdit(CurrentNode);EditNode(CurrentN- 
ode); 

( 10 ) end if; 

(11) 

3.5.2 MARVEL 

Several published papers describe the evolution of the Marvel environment. Marvel 3.1 
offers a process modelling language referred to as MSL, with the three main constructs 
being classes, rules, and tool envelopes. 

Classes have attributes that can be typed attributes or links to other classes. The fol- 
lowing examples, taken from [Barg93] show some simple class definitions: 

( 1 ) SUBSYSTEM :: superclass ENTITY; 

( 2 ) MRs : set_of MR; 

(3) modules : set_of MODULE; 

(4) end 

(5) MR: superclass ENTITY; #modification request 

(6) contents: text; 

(7) status : (new, open, screened, inprog) = new; 

(8) name: text; 

(9) end 
( 10 ) 

( 11 ) EMPLOYEE :: superclass ENTITY; 

( 12 ) level : (MTS, TechManager, Dept, Head, Secy, Office_manager) = MTS 

(13) # default value is MTS 

(14) login : user; #the login id 

(15) office : string; 

( 16 ) phone : string; 

(17) dept : string; #department number 

( 18 ) boss : link EMPLOYEE; 

(19) teams : set_of link TEAM; 

( 20 ) current_tasks : set_of link TASK; 

( 21 ) end 

Rules declare pre- and post-conditions and a code part. In the following, we give a 
very simple example of a rule [Barg93]. 

(22) 

(23) solve_MR[?mr:MR] : 

(24) : 

(25) no_chain(?mr. status = open) #precondition 

( 26 ) {IMRDB mrsolve ?mr.name} 

(27) (?mr.status = solved); 
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The rule declaration models the creation of a code solution for an individual modifi- 
cation request, after which the status of the modification request changes from “open” 
to “solved”. 

Recently, the Activity Structures Language (ASL) [Kais94] has been implemented in 
the context of Marvel. ASL is a variant of Riddle’s constraint expressions that allow the 
modelling of process model topology by means of regular expressions extended with 
concurrency operators. ASL fragments can be translated into MSL. 

3.5.3 Process Weaver 

Process Weaver is based on an internal PML, hidden to the user, and usable by a 
number of views. The elicitation meta-phase is facilitated by the highest abstraction 
level called the method level. Here, we can define decomposition hierarchies of activity 
types. An activity type can be regarded as a specification, or interface, that can be asso- 
ciated with a textual description of related roles, products, and techniques. Process 
models can be designed by cooperative procedures that express activity control flow. 
Cooperative procedures are expressed in a Petri net like language. Each Petri net tran- 
sition can be associated with a pre-condition and an action that are expressed in the 
CoShell PML. Work assignments can be described by a special PML with so-called 
Work Contexts. The WorkContext level offers tool classes to map from Work Contexts 
to local tools. Product modelling is not explicitly supported and product place holders 
can be expressed by CoShell variables.. 



Table 3.5 Process elements and existing PMLs 
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Process Weaver provides special graphic editors to manipulate activity types, coop- 
erative procedures, CoShell conditions and actions, and Work Contexts. In Tables 3.5 
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and 3.6, these three PMLS are mapped against the process elements and the meta-proc- 
ess phases. 



3.6 Possible Groups of PMLs and PSEEs 

PMLs and their respective PSEEs can he classified into four categories: 

• Those that are product-centred on software engineering databases: this category 

includes the EPOS and Adele systems. The associated PMLs are often object-ori- 
ented. 

• Activity-centred PMLs. These PMLs are designed around the need to provide support 

for activity description. Examples are MARVEL, MERLIN, OIKOS, Tempo (the 
part based on rules and triggers). Process Weaver, SPADE, MELMAC, EPOS (the 
part based on the activity network), and APPL/A (that provides an imperative PML). 
This approach is popular and has the substantial advantage of enabling representa- 
tion of concurrent activities together with their synchronization and communication 
constraints. On the other hand, one can argue that process models are more than sim- 
ply concurrent programs. 

• Project-centred PMLs. These take as their starting point a project management view 

on the process. Examples are CADES, ISTAR, the Virtual Design Team, Microsoft/ 
Project. 

• Role-based PMLs. These are centred around human-based roles and their interac- 
tions. Examples are PWl and many groupware or speech-act systems. 

Alternatively, one can divide existing PMLs according to the following dimensions: 

• Functional: they mainly describe what activities are performed. 

• Behavioural: they are centred around the “when” and “how” of the process, i.e., when 

and how activities are performed. 

• Organizational: they are centred around the “where” and “by whom” dimension. 

• Informational: they are centred around artifacts, processes and their relationships. 



Table 3.6 Meta-process phase and existing PMLs 
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3.7 Conclusion 

Until recently, the body of research in process modelling has been focused on different 
linguistic paradigms for the core PML in order to find the correct one. Our position now 
is that the idea of one standard, all-encompassing PML, is utopia. Theoretical problems 
and interoperability requirements (discussed in Section 3.3.8) have made this solution 
almost impossible, and we should lift our perspective up from that of low-level activity 
formalisms. 

To recapitulate: there is a wide variety of process phases and elements to be covered, 
although the community has concentrated much on the Implementation and Enactment 
phases of the software development meta-process. We must also interface towards 
actual production tools/workspaces. Different user roles have different needs, work 
modes and user interfaces. 

There are many technical arguments behind choosing one core PML and a set ofsub- 
PMLs however the decisive factor in choosing the “federated” “interoperable” 
approach, is that we have to adapt to a myriad of relevant through alien languages, tools, 
and databases. All of these must somehow be incorporated into or interfaced against the 
PSEE. That is, simply that the PSEE developers alone do not control the PML design 
space. Thus, interoperability against standard or existing subsystems is an absolute 
must, especially since process support should augment existing computerised produc- 
tion tools, and not be a hindrance. 

We even claim that the choice of the underlying linguistic paradigm for such a core 
PML, which must cover the primary process elements, is relatively unimportant. What 
really matters are: 

• Actively reusing technology (both conceptually and technically) from related 

domains such as Information Systems, Enterprise Modelling, Business Process 
Reengineering, Project Management, and Quality Assurance. 

• Standardisation, the adoption of common PM concepts and formalisms. 

At the very least, a taxonomy is needed for classification and assessment of such con- 
cepts and formalisms, and of common process models (cf. ISPW6 example). In a 
more practical vein, “reuse” is a keyword to be applied to the utilization of standard 
support technologies such as Unix/MS-DOS, C-H-, CORE A or ODMG and X/Motif. 

• Interoperability: 

This is the need to make PSEE components interact smoothly with other process and 
production models and tools. Modularization, open systems and above standardiza- 
tion are keywords here. Some concrete issues to consider are: 

- coupling to Configuration Management, multi-actor and distributed; 

- coupling to Project Management; 

- coupling to Quality Assurance and Software Process Improvement (ISO 9001, 
CMM); 

- coupling to Groupware and social processes; 

- coupling to Organisational theory (BPR, EM). 
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From a PML perspective, this means that the different languages, offered by the exist- 
ing systems have to be integrated around 

• Easy user-level evolution of the process model; 

The goal is to provide an understandable view of both model and model change pol- 
icies, so that this can be changed by the process agents themselves, if and when 
needed. 
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4.1 Introduction 

4.1.1 Overview 

Our concern is with the modern software production environment and, as mentioned in 
Section 1.7 we can focus our interest by exploring the distinction between a process 
being carried out in the real-world, and a model of that process. These two facets are; 

• a real-world production process (P) including human participants or actors, CASE 

tools, etc. which encompass all activities needed to produce software products, and 

• a software process model (PM) which is a representation of the real-world activities 

for guiding, enforcing or automating parts of that production process. 

This can be illustrated by adapting Figure 1 in Chapter 1 to Figure 4.1 over. Real- 
world process activity is comprised of P plus a (possibly null) PM in the world of proc- 
ess enactment (if a model exists, then it is itself a part of the real world). To execute a 
process P in accordance with a process model PM, one must first customise a “tem- 
plate” model in order to get an “enactable” PM tailored to the specific process. Through 
instantiation this model becomes an “enacting” instance which will coordinate actors 
and machines in the execution of the real-world process ^This has led to closely related 
issues such as understanding what we know and do not know about process, the creation 
of formalisms suitable for describing and representing processes, issues about automat- 
ing the software process and developing methodologies, tools and environments for 
engineering and controlling the evolution of processes. 

As has already been mentioned in Chapter 1, there can be many good reasons for 
deciding to change a software process, and a well-structured change of the software 
process implies; 

• evolution of the (real) process P, and 

• evolution of the process model PM.. 



I . In the following sections of this chapter, for reasons of simplification, the term “process model” 
(PM) encompasses all template, enactable and enacting variations. 

J. C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 53-93, 1999. 

© Springer-Verlag Berlin Heidelberg 1999 
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Figure 4.1 The relationship between Process Reality and Process Model 

When a real-world production process (P) is modelled in a process model (PM), prob- 
lems arise when P alone evolves. PM and P may no longer be in accordance because an 
evolution of PM, based on the evolution of P, has not yet been performed. The process 
models (if they exist) have to evolve, and furthermore, considering the opposite sense, 
one may even use evolution of a model to enforce an evolutionary change in the corre- 
sponding process (P). 

From an engineering point of view evolution of a software process is itself a full proc- 
ess. This process is called the meta-process. Such a process would include steps for 
changing the real-world process and others for introducing changes in process models. 
Its main role is one of assurance that P and PM remain consistent. 

Performing change to the real-world process is a complex and expensive task, and in 
many cases must take place frequently. As a minimum, users performing the real-world 
process need to be told that it is changing and, depending on the complexity of the 
change, it may be preferable to introduce changes in several stages. This being the case, 
it is useful to identify recurring activities and to define a process-evolution process. For 
example, a step in changing the real-world process referred to in [Conr94a] is that of 
user awareness and training for a new tool. 

Modelling is an activity which requires skill and rigour. The evolution of a process 
model is usually the consequence of (at least partly defined) reasoning, and in that sense 
it is logical to consider the evolution of process models as a true process. An example 
of process model evolution could be the change of a review process model from cross- 
readings to Fagan [Faga76] inspections. 

There are two kinds of process model evolution to be considered. The first is correc- 
tive/perfective/adaptive evolution: evolution with the objective of, or the need to, repair 
manifest defects, improve quality or performance of existing well-defined activity, or 
to avert a degradation of performance. This change is usually (but not always) initiated 
on the basis of information fed back from the performing process. There is another 
aspect of evolution which has, as yet, only rarely considered from the point of view of 
enactable process models. It will be unusual for an enactable process model to exist 
from the outset as a complete and detailed definition. Models with static definitions are 
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of limited use. There is a clear need in industry for dynamic models which can be 
refined from a template and thus evolve as objectives are refined, become better under- 
stood, and become more specific as the project develops. Evolution through refinement 
takes place primarily by the decomposition of objectives (as exemplified precisely in 
Appendix C). 

As presented above, the (real-world) process-evolution process and the process- 
model-evolution process are two of the components of the meta-process. These proc- 
esses can be modelled in the same way as any other operational process and their model 
is called the meta-process model. 

In this chapter we will present a reference meta-process model (called the Promoter 
Reference Model, or PRM) which will provide; 

1) a simple framework for structuring meta-process activities and, 

2) a methodology for specializing and refining these activities into concrete tasks taking 
into account specific environmental constraints (such as particular process support 
tools needs, quality standards, etc.). 

4.1.2 Meta-Process and Quality Improvement 

Quality is defined in ISO 8402 and 9126 as “the totality of characteristics of any entity 
that bear on its ability to satisfy stated and implied needs” [IS091b]. Moreover quality 
improvement, is defined as “the actions taken throughout the organisation to increase 
the effectiveness and efficiency of activities and processes to provide benefits to both 
the organisation and its customers”. The aim of improving the quality of software prod- 
ucts requires that the quality of the software development process has to be improved. 
In order to take such improvement actions in a meaningful way, the organisation must 
be assessed and improvement goals must be set, both at the organisation and the project 
level. There is also need to determine whether or not the actions taken were sufficient 
to achieve the stated goals, and then to react if they were not. The production process 
has to be measured in some way and the measurements have to be analysed and used in 
order to improve the production process. 

The following infrastructure technologies must be in place for systematic quality 
improvement to be brought about: 

• Explicit modelling of products, activities and quality aspects. 

Modelling is necessary in order to understand the building blocks of software 
development and to be able to tailor them for specific needs, measure their adher- 
ence within different projects and to improve them across projects. 

• Comprehensive reuse of models, knowledge and experience. 

Reuse is necessary in order to choose appropriate models for new projects and to 
compare actual project data with baselines. 

• Measurement integrated with the software development. 

Measurement needs to be goal-oriented/model based and are used for defining 
quality goals, understand differences between projects and to control whether 
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quality targets have been met [Basi88]. The data from the execution of the pro- 
duction process would be saved in an “experience base” as execution history of 
the project. Naturally focusing on developing software, a production process still 
has a number of other tasks to attend. Typical examples are the continuous collec- 
tion of measurements and the monitoring and control of the process performance 
based on the measurement-specific feedback. Feedback analysis should be 
applied to guide the project’s decisions and to adapt process improvement initia- 
tives based on experience. 

If the improvement meta-process is executed by the use of models and methods, man- 
agement and developers will be better able to: 

• understand the development process(es) and the factors that influence quality, 

• monitor and control development process(es), thus improve predictability, 

• alter and improve the development process from one project to the next. 

4.1.3 Existing Meta-Processes 

At present, meta-processes proposed in the literature make no clear distinction between 
real-world process evolution and process model evolution. We can say that “normative” 
meta-processes like CMM [Paul93b] SPICE [Sand70] and AMI [Pulf95] focus more on 
aspects of real-process-evolution than on those of process-model-evolution. They are 
concerned about how planning and guidance of process improvement impacts directly 
the work of human (and non human) actors. 

In CMM one can find some guidance for process improvement via Process and Tech- 
nology Change Management key practices. AMI is a quality-driven meta-process 
which is divided into four major steps: MS 1 — Define primary goals using for example 
the CMM; MS2 — Derive metrics based on the GQM [Basi88]; MS3 — Implement a 
measurement plan; MS4 — Exploit your measures. 

Another class of meta-processes focus more on the process-model-evolution process. 
The Process Cycle [Madh91], the Prism model [Madh90], and QIP [Basi93] are some 
examples. Moreover several works on conceptual frameworks for process modelling 
and process improvement propose ways to change process-models [Dows94] 
[Conr94c]. Warboys[Warb89] proposed a model of change through support of manage- 
ment control of the production processes. 

In the Process Cycle proposed in [Madh91], engineering, management, performance 
and improvement of software process are integrated in three “sectors” (A, B, and C). 
The process cycle bounded by those three sectors defines the scope of the total set of 
process steps necessary for the development and evolution of process models. In sector 
A, process engineers design, construct and improve generic process models according 
to project-free goals and policies. The descriptions developed in sector A are then 
adopted and customised by process managers of sector B for use in specific software 
projects; process managers are subjected to project-specific goals and policies that 
influence the customisation process. In sector C, process performers (i.e. software 
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developers) carry out software process, in order to build and improve the application 
software. 

Prism [Madh90] is a process-oriented environment supporting methodical develop- 
ment, instantiation, and execution of software process models. Prism architecture has 
been designed to hold a software process description, the life cycle of which is sup- 
ported by an explicit representation of a higher level (or meta) process description. In 
Prism the major steps involved in building a generic process are: a) requirement engi- 
neering: a user requirements document describes what the customer needs and the 
project requirements document describes what the project needs in order to satisfy the 
customer requirements b) review of the requirements gathered: the meta-process inter- 
preter requests for a review group to be set up and eventually informs the reviewers of 
what is expected from them, c) specification and design of process fragments: the key 
concepts at this level are abstraction and refinement, identification of process modules, 
specification of module interfaces and design of process bodies, d) review of specifica- 
tion and design: once process fragments are designed (or tailored) static properties 
(such as deadlock, starvation, etc.) are proved using appropriate tools and dynamic 
behaviour of the software process is observed (frequency counts, object-flow, delays, 
etc.). 

The Quality Improvement Paradigm [Basi93] aims at addressing the issues of quality 
improvement in the software business by providing mechanisms for continuous 
improvement. The basis for the QIP approach is explained by the following six steps: 
1) Characterise the project environment based upon the available process/product/qual- 
ity models, data intuition, etc. 2) Set goals on the basis of the initial characterisation and 
strategic goals for successful project and organisational performance and improvement. 
3) Choose the appropriate process models methods and tools on the basis of the charac- 
terisation of the environment and of the goals that have been set 4) Perform the proc- 
esses for constructing the products and provide project feedback based upon the data of 
goal achievement that are collected. 5) Analyse the data and the information gathered 
to evaluate the current practices after the completion of the perform step. 6) Package the 
experience gained in the form of new or updated and refined models as well as other 
forms of structured knowledge gained from this and prior projects. Store this informa- 
tion in an experience base so that it is available for future projects. QIP is used to struc- 
ture process evolution at NASA’s Software Engineering Laboratory. 

Conradi [Conr94a] remarked that “it is not possible to identify one universal meta- 
process for all possible processes. However it is possible to define some basic general 
meta-activities that constitute the skeleton of any meta-process: 

• Technology provision. This meta-activity is in charge of producing or acquiring the 

production support and the process support. 

• Process requirements analysis. This meta-activity takes into account the production 

process, the meta-process and the existing process support to provide (new) require- 
ments to the design meta-activity. 
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• Process design. When a new process is created, or if the new requirements for an 

existing process are identified, this meta-activity provides the general and detailed 
architecture of the process. 

• Process implementation. This meta-activity is in charge of implementing the design 

specification produced by the previous meta-activity. Process implementation 
includes the two conceptually distinct aspects of 1) changing the process support and 
2) changing the real-world process. 

• Process assessment. This meta-activity provides quantitative and qualitative informa- 

tion describing the performance of the whole process.” 

The set of the above activities gives an indication of the fundamental steps that have 
to be taken in order to manage a software process, and these have been refined in Chap- 
ter 3 Section 3.2.2 into the six phased meta-process for software development. 

The compatibility between the real-world process P and the enacting process model 
PM is not supported a priori by existing meta-process models. Having a process-centred 
system which supports evolution increases reliability of P and PM changes. At present 
we are still far from having available process-centred systems providing complete proc- 
ess model evolution support [S-I93]. To ensure that P and PM are still compatible after 
a cycle of evolution, a clear methodology should be defined which enforces rules and 
is applied when invoking change in P and/or PM. Defining precisely such a methodol- 
ogy and its associated process is not easy, because; 

• evolution is needed because the process and its model are no longer compatible, 

• starting from this incompatible “data”, evolution should produce a process and a 
model which are compatible. 

In addition, evolution needs can range from changes to a small and well identified 
part of the process (or process model), to substantial improvements involving process 
re-engineering and other possibly revolutionary changes. In all these different classes 
of evolution, common meta-process patterns to implement changes can be identified 
(see Section 4.4). A meta-process model must be flexible in order to help process mod- 
ellers express these patterns in a simple and reflexive way, to solve both simple as well 
as complex problems using a single consistent methodology. 

In this chapter. Section 4.2 identifies requirements for meta-process. The basic prop- 
erties of a model for the meta-process are given in Section 4.3. The PRM is presented 
in Section 4.4 and validated with respect to requirement in Section 4.5. Section 4.6 
presents three widely accepted meta-process models (QIP, Prism and “Process life- 
cycle”) as specific cases of the PRM model. A special Section 4.7 proposes a view of 
CMM as a meta-process which is also a specific case of the PRM. This view of CMM 
is implemented in Section 4.8. Finally the benefits from using well defined meta-proc- 
ess models to install a software process are discussed in Section 4.9. 
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4.2 Requirements for a Meta-Process 

In Chapter 1 a simple example of change to a software process was described (Section 
1.4). This is in fact a case of an informal evolution process comprised of the following 
three steps: 

1) Analyse the behaviour of the process model in use and formulate objectives for evo- 
lution. 

2) Create a new process model. 

3) Enact it and observe its behaviour. 

The resulting process model, which can be used in the subsequent CCB Request, 
deals with sophisticated CASE tools like configuration managers and introduces coor- 
dination problems between parallel activities of human actors. All the new problems 
introduced must be addressed in a coherent manner in order to keep consistency with 
old techniques and habits. 

To support, guide or enforce process evolution it is essential to develop a meta-proc- 
ess model describing objectives and actions for change to the software process. It is 
obvious, even with such a small example, that formalizing the meta-process is a com- 
plex activity taking into account organisational as well as technical constraints. A first 
step to model software process evolution is to identify detailed requirements for the 
meta-process which must be addressed by all meta-process models. 

Section 4. 1 has identified some shortcomings of existing meta-process models in sup- 
porting evolution of both real process and process models in a coherent manner. The 
requirements specified below are essentially derived from both these sections, and the 
desirable characteristics identified in [Nguy94]. 

The user is the ultimate arbiter as to whether or not the formalism will be of value to 
practitioners. By “user” we mean anyone concerned with the evolution of organisation 
processes: be they software processes, insurance processes, or other kinds of produc- 
tion-like processes. Essentially they are those responsible for ensuring satisfactory per- 
formance of the processes, but also include those contributing to the process as 
participants. 

The following requirements reflect the needs identified from the point of view of the 
user of meta-process model. 

• Simplicity: Real-world operational processes are very complex, in fact more complex 

than we can, at present, represent. Thus the formalism for changing this complex 
entity will be an order more complex again. It is essential, therefore, that the meta- 
process model is of the simplest construction. Whatever methods are involved 
should be well-known and well-defined. 

• Genericity: The meta-process model must be generic to allow adaptation (or tailor- 
ing, or customisation) in a manner appropriate to a particular organisation, domain, 
and purpose. 
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• Extensibility: The meta-process model should be open-ended, enabling extension if 

this is found appropriate from experience of use, development of knowledge, etc. 

• Flexibility: A) The meta-process model must be constructed such that, ultimately, 

end users should be able to tailor their portion of the operational model to ensure an 
optimum mapping of skills to tasks. B) The meta-process model must recognise and 
allow different models of change: corrective change, improvement change, exten- 
sion change, adaptive change, and refinement change. C) The meta-process model 
must be capable of applying change to all, or selective parts, of the process model, 
be they existing in the form of definitions or enacting instances. It must be possible 
to apply change selectively. 

• Robustness: It is frequently the case that real-world processes are very complex and 

rarely in absolutely stable states of development.The meta-process model must be 
able to address the situation where processes are incompletely defined. 

• Interface Management: There will almost always be a tension between the defined, 

enacting process model and the real-world process which it supports. The meta-proc- 
ess model must provide for managing this interface and to allow inconsistencies to 
be resolved. 

• Integration: The meta-process model should support implementation and integration 

with existing process technology in order that existing organisation and project struc- 
tures, working practices, communication patterns, software assets etc. are retained 
and utilised. 

• User support: The meta-process model should be fault-tolerant and be able to pro- 
vide sufficient guidance and assistance to users during the performance of meta- 
process activities. The use of the meta-process model should, wherever possible, be 
intuitive. 

• Economical benefit: The application of meta-process model supporting process evo- 

lution should clearly demonstrate a measurable advantage or pay-off (e.g., improve- 
ment of productivity, predictability, and quality) compared to the time and cost being 
spent to install, operate and maintain it, train staff, etc. That is, the meta-process 
model must be cost-effective, and impose a minimum of additional organisational 
overhead. 

• Strategy: The meta-process model must be able to take cognisance of an organisa- 
tion’s strategies and rules, and guide users to the proper application of these. 

• Implemen table: The meta-process model should be capable of being implemented in 

current technologies and be open to new technologies. 

• Enactable: The meta-process model must be capable of interaction with human proc- 

ess participants and be able to change its state accordingly. 
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4.3.1 Introduction 

Certain of these requirements establish a perspective from which the problem as a 
whole can be viewed. For example, the need for “integration” implies that a new solu- 
tion ought not to compete with existing solutions, but rather should complement them, 
to take best advantage of work that has gone on before. It also implies a search for prop- 
erties that are missing from existing solutions. 

The primary focus for this work was in fact provided by the requirements for simplic- 
ity and genericity in the meta-process. Existing examples have tended to become more 
complex as workers have attempted to address ever more of the manifold concerns aris- 
ing from real-world complexity. The need for simplicity prompts inquiry into what 
might be the essence of a meta-process, and, if the model cannot be made complex, then 
some other means has to be found to address the complexity of the real world. The chal- 
lenge then becomes one of abstracting from the observed real world to find a core of the 
meta-process, and endowing this core with suitable properties such that it can be 
adapted as required to sensibly and usefully model the real world. 

This section will develop a model of the core behaviour of a meta-process, and dis- 
cuss three properties which are essential if this model is to be capable of addressing 
complexity issues. These properties are: task decomposition, method specialisation, and 
consistency management. 



4.3.2 Control and Problem Solving 

The concept of a core behavioural model of the meta-process will be developed by posi- 
tioning the meta-process relative to management control processes in systems context, 
and then to study control processes as processes which regulate by solving a succession 
of “problems”. 

The control system of an organisation is one whose purpose is to influence, guide or 
to regulate organisational activity and resources in order to achieve certain desired ends. 
This is what is commonly understood by the term “management”. It is susceptible to 
influences both from within the system, and from outwith the system, and is able to 
respond to both. That part of an organisation’s overall control system which seeks to 
ensure the achievement of desired outcomes by the regulation of process behaviour is 
the process control system. These influences are called (from control theory) feedback 
and feedforward. The former represents the mechanism whereby some component of 
the outputs of a system are used to manipulate the inputs to the same system, and the 
latter is a technique for making use of environmental factors to anticipate the need for 
changes in a system. Organisations make much use of both. Feedback can be of two 
kinds, negative or positive, depending on the use to which it is put. The former acts to 
reduce any change tendency in the outputs so tending to stabilise the output, and the lat- 
ter serves to reinforce any tendency and is thus used in, for example servo-mechanisms 
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or resonant circuits. The effect of feedback on systems evolution [Lehm85] and on soft- 
ware project management processes [Hami90] have been studied for many years. 

Now this regulation can take a number of forms. The most common is regulation of 
inputs, or of resources, but the form in which we are primarily interested is regulation 
by changing the subject process. This work makes the basic assumption that the meta- 
process of the software development process is a specialism of such a management sys- 
tem, insofar as organisational activity is in fact believed to be predominantly process 
centred. This view is close to that of Conradi et al. [Conr94c] (“part of the process 
involved in maintaining and evolving the whole process”) and is a wider definition than 
that previously expressed by Lonchamp [Lonc93], (that the meta-process is one which 
describes the “engineering” of processes). 

There are a number of possible starting points for developing this concept, including 
Schon [SchoSl] (in the domain of problem-solving by professional workers). Beer 
[Beer66] (cybernetics), Checkland [ChecSl] (“soft” systems), and others. 

The difference between “what is” and “what ought to be” constitutes the core of many 
management concerns, and this can be represented as a continuum of problems to be 
solved. We will use a very simple model based on work on the general problem solver 
by Simon [Simo69]. Viewing the organisation as an adaptive organism, Simon believes 
that there is a class of problems whose solution recognises a fundamental relationship 
between state and process; between the world “as sensed” and the world “as acted 
upon”. 



“We pose a problem by posing a state description of the solution, then the task 
is to discover the sequences of processes (sic) that will produce the goal state 
from the initial state. Given a desired state of affairs and an existing state of 
affairs, the task of the adaptive organism is to find the difference between these 
two states and then to find the correlating process that will erase the difference.” 



This is the “systems” view of problem-solving, where it is recognised that problems 
must be seen in relation to the context within which they exist. It does, however, assume 
that actions will always have the desired effect. In fact this is unlikely to be the case, 
and there needs to be constant re-appraisal of the likelihood of the goals being achieved 
- there needs to be a continual feed back of state information to enable the intent of the 
system (as described by objectives) to be maintained as much as possible. 

This class of problem can thus be characterised as process activity with three foci; 

• deciding what to do 

• devising some course of action 

• carrying out this action, and seeing how effectively it is being carried out 

This behaviour is illustrated in Figure 4.2, and is in fact also the basis of the so-called 
“Management Paradigm” referred to in Chapter 8. 
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the process view 



Figure 4.2 Generic problem-solving 

We can thus take this system perspective of purposeful human activity, exclude any 
behaviour or properties which are not process-centred (because we are not equipped to 
address such issues), and develop it into a model capable of being implemented in a 
process-centred environment. The first step is to describe this process view of problem- 
solving as a way of handling inconsistencies. 



4.3.3 Consistency Management 

Some kind of consistency, or agreement, must be sought, between the real world per- 
formance of a process, and the underlying model which is guiding the performing of this 
process. A “consistent” relation means that the model provides perfect support for the 
real process, and experience leads us to believe that this state of affairs can rarely, if 
ever, be met. Even if these two domains were at some point in time consistent with each 
other, they are unlikely to remain consistent for very long. Thus an inconsistency can 
be viewed as a problem to be solved. The reconciling of inconsistencies is not a one-off 
problem, it is a continuum of problems, and furthermore it is unlikely that inconsisten- 
cies can ever be entirely eliminated; rather, the best result that can be hoped for is the 
elimination of some and a mitigation of the undesirable consequences of those remain- 
ing. It is therefore more of a management issue than a problem-solving issue. This is not 
a new perspective: Osterweil has pointed out [Pene88] that “Software projects are all 
about inconsistency management”. 

This is a very general behavioural model of what, in practice, is a very complex proc- 
ess. It is generic, representing the essence of activity which is of importance at this level 
of abstraction, but is not meant to be a complete or comprehensive process description. 
To be of use, this model would have to be adapted to reflect and accommodate charac- 
teristics of the problem domain, the specific problem, and also the organisation context 
in which the solution had to be effected. Thus although the three activity components 
of the elementary model appear sequential, in reality they involve complex relation- 
ships which are much more than simple temporal dependencies. The components of the 
problem-solving process are: 
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Establish a goal. This represents the identification of the state of affairs in the domain 
of interest which can be something manifestly wrong and which must be corrected, or 
in fact an opportunity to be exploited. Goals are rarely simple and may need refining 
through numerous stages before a suitable method can be established. In the case of 
software development, a client statement of need for a software system may be enough 
to trigger the production process, but knowing which process to adopt may well depend 
on a more detailed analysis of the problem. 

Devise and install a process model. When a suitable set of requirements have been 
established, the search begins for some logical method, or pattern of abstract activity, 
which will achieve the desired outcome. This search seeks generic solutions. The solu- 
tion can be found in experience (personal or organisational) or from libraries, databases, 
etc. If no method can be found, then it will have to be created. If it is impossible to gen- 
erate a method, then either new information resources will have to be found and 
searched, the goal changed to one which is attainable, or the attempt abandoned. There- 
fore, referring again to Figure 4.2, although the arrow between Establish and Devise 
implies the passing of a goal, it must in fact represent a negotiation about this goal. 

With the generic solution to hand, it must then be adapted to cope with the specific 
requirements and for the particular organisation unit which will actually do the work 
and solve the problem. When the method has been satisfactorily adapted, the process 
model can be installed, i.e. people requested to participate, machines configured, tools 
installed etc. This is change to the real world, and is represented in Figure 4.2 by the 
arrow between Devise and Enact. Thus the outcome from this activity is a known proc- 
ess and a knowledge of the resources necessary to bring it about. 

Enact the process model. The behaviour in this domain actually invokes the transfor- 
mations that are necessary to provide the solution. The behaviour is guided, to a greater 
or lesser degree, by a model of the process. This may be a passive model, on paper, or 
simply “known”, or it can be an active model, supporting the process. An active model 
is one which can sense events and respond by changing its state accordingly. People can 
interact through their computer systems with the process model, using facilities availa- 
ble through the system to contribute as needed to the process. There is communication 
to the objectives-setting activity (indicated Figure 4.2 by an arrow) of some measure of 
progress towards the achievement of the goal. This enables corrective action to be 
implemented if it is becoming clear that the existing process may be inadequate to 
ensure a satisfactory outcome. 

This can be regarded as a form of feedback. There are really two “inputs” to the prob- 
lem-solving-process: one is the problem statement, and the other is some knowledge 
about the actual state of the problem solving process. The latter is nil at the start of the 
process, and gradually increases to 100% when the problem is finally solved. The 
knowledge obtained from this feedback represents a knowledge of state of the process, 
and is compared with some model of what state the process ought to be in if it is likely 
to solve the problem. Inconsistencies between these states can thus be identified, 
assessed, and, if necessary, corrective remodelling of the process model can be under- 
taken, and re-installed 
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The form of this process-solving process model can be seen in the behaviour 
described in the conclusions to the simple evolution example in Section 1.4. This pro- 
vides early evidence of generic behaviour. 



4.3.4 Task Decomposition 

There are many techniques which can be used to address the problem of complexity, 
and one of the most common is that of modularity or decomposition. When a task can- 
not be dealt with as it stands, because it is too big, or too complex, then it can be bene- 
ficial to somehow split the task into component tasks. If these components are tractable 
then they can be undertaken, solved, or designed, and the whole re-created by combin- 
ing the results of the components. This can be an effective way of dealing with other- 
wise unmanageable problems, objects or behaviours, however it is dependent on 
nothing of importance, particularly emergent^ properties, being lost in the decomposi- 
tion, and care must be taken that this is in fact the case. 

Referring to Figure 4.2, for each goal there is an associated method, and this method 
may be fully defined, but equally the definition may be incomplete. In fact it may com- 
prise only sub-goals, and the overall objective is satisfied when each of the individual 
sub-goals are satisfied. The set of decomposed tasks can therefore be thought of as a 
method, and the model can develop into a network of goals and sub-goals, the link 
between them being a statement of the problem. 

The full definition of the model can be visualised as a tree structure which has as its 
“root” the fundamental problem statement. The leaves are the methods which can them- 
selves be statements of objectives for which further methods are required. This devel- 
opment will continue until the methods described in the leaves are sufficiently well 
defined as to allow them to be used by people to develop a partial solution. The sum of 
all these partial solutions is hopefully the solution to the original problem statement. 

This decomposition and subsequent recomposition can take place as part of “devising 
a solution”, but equally it can be done as one of the phases of the solution process (It is 
often the case that the actual method for solving a problem may become apparent only 
after some initial work has been done towards solving the problem). This refinement 
may take place as the solution process is being executed. 

There is a useful analogy to the planning process. The nature of the passive process 
model (i.e. the plan) changes continuously as the project (either a personal project or an 
organisational project) develops towards conclusion. At the outset of a project, only the 
framework is known, and activities are identified only by dependencies and delivera- 
bles. As the project develops and process knowledge and experience accumulate, so 
these activities can be refined, usually by decomposition. This is carried out as and 
when necessary, when the detailed information for guiding the physical work is needed. 



2. Properties that do not pertain to the parts but which are a property only of the whole. 
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The essential requirement is that the details have to be known before the activity is due 
to be undertaken. 

4.3.5 Method Specialisation 

It has been mentioned that the proposed model, to be of utility, must be adaptable and 
must maintain the structure of the operational process model. This can be addressed by 
endowing the model with specific properties for handling problem-solving methods. 
Little is known of the structure of problem-solving methods. In practice, problem-solv- 
ing methods have become inextricably intertwined with and buried in domain-specific 
knowledge, and generic methods are rarely recognised as such, and, when they have 
been discussed, it has almost invariably been in the mathematical domain [Poly90]. 
There is no formal structure with which to categorise and characterise problem-solving 
methods. 

The advent of object-oriented technologies facilitating typing and inheritance of def- 
initions has lead to consideration of a possible structure of such methods. This requires 
that definitions of method are, at each level of abstraction, only given in sufficient detail 
for that level of abstraction. Existing problem-solving methods frequently adopt the 
strategy of seeking a problem that has been solved before, generalizing the solution, 
then adapting that solution for the current circumstances. The possibility now exists to 
maintain a set of generic solution methods, to have some way of choosing among them, 
and for adapting the chosen method for the task and to the organisation such that this 
method might in turn become a standard solution 

As an example, consider the preparation of a document in an organisation. The “prob- 
lem” is to prepare a document in an appropriate format. If the department has a standard 
format, then this constitutes the “method”. However if the department hasn’t got a for- 
mat, then recourse has to be made to the organisation’s standard format, possibly 
adapted for the department. If that does not exist, then a “format construction” method 
must be sought to create a format ab initio. 

If a “format construction” method is not known, one will have to be developed. This 
is done by stating a sub-problem of “How to develop a method”, and devising and 
installing a process model of a method of developing a method of constructing a format 
(if it can, in fact be described in process terms) and enacting this process model. 



4.3.6 Remarks on the Model 

This section has derived an elementary behavioural model of the meta-process and 
introduced two concepts to deal with complexity in the real world. These latter are dis- 
tinct but are linked through the property of inheritance: when a task is decomposed into 
sub-tasks, each of the sub-tasks inherits the methods from the parent Task, and uses 
these methods as the basis for developing a solution in the form of a process model. 
Sub-tasks can have knowledge of all methods available to the parent task. 
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The meta-process model thus far described in this section has its origins in an under- 
standing of human intuitive thought processes. The prime concern of this book is of the 
software development process — a process dealing with complex objects in a complex 
environment coordinating the creative efforts of many people and the power of many 
machines. To address this problem, the meta-process model must be properly integrated 
with the proposed properties as described in the following Section. 



4.4 PROMOTER Reference Model (PRM) 

In this section we present a specific meta-process model called Promoter Reference 
Model which incorporates all properties stated in Section 4.2. After a presentation of 
the basic model structure we show how method specialisation, task decomposition and 
consistency management are combined in a core minimal model. 

4.4.1 Model Structure 

In order to implement a model for the meta-process we will start with a small number 
of obvious observations arising from the last section; 

• The meta-process, just like any other process, is characterised by a set of task objec- 
tives. 

• Each task fulfils its objectives by seeking and performing a method. 

• Task objectives and their associated method can constitute a tuple: <task objectives, 

method> (although of course this relationship may be by no means simple). 

• A method is either specified ah initio or derived from an existing method by special- 

isation (see Section 4.3.5). 

• Tasks are not all at the same level of abstraction (see Section 4.3.4). An abstract task 

is decomposed into sub-tasks comprising its associated method. Task decomposition 
is done recursively until basic tasks (activities which can be physically carried out) 
are identified. 

• Unfortunately tasks are not always well defined and methods are frequently inade- 
quately adapted to the corresponding tasks. Thus it is necessary to obtain feedback 
from task performance in order to verify the adequacy of the applied method and to 
enhance effective work. 

All the above items reflect the standard steps of any process. As stated in Chapter 1, 
supporting the process by means of a model is beneficial for various reasons. 
Section 4.3 identifies the basic properties which should be addressed by a meta-process 
model. The MPM is, of course, far too abstract to be of assistance to practitioners. The 
task is therefore to specialise this model for the problem domain of software engineer- 
ing by introducing, within this framework, concepts which are specific to that domain. 
This model is termed the Promoter (meta-process) Reference Model (PRM) and is illus- 
trated in Figure 4.3. 
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Figure 4.3 The Promoter Reference Model 

The PRM integrates the three basic notions of method specialisation, task decompo- 
sition and consistency management (see Section 4.3) in a simple meta-process model in 
which: 

• Task Analysis encompasses behaviour associated with the defining of objectives for 
a particular task to achieve certain goals. 

• Technology Provision encompasses behaviour which provides a model defining the 
method to perform the task. 

• Realisation encapsulates behaviour which adapts this model to the organisational 

context, and thus associates the specific task objectives with this model 

• Enactment corresponds to task performers’ work guided by model enactment. 

In this context it is important to get Enactment feedback to check if task performance 
is consistent with respect to the behaviour described in the model. 

Referring to Figure 4.3, Task Analysis and Realisation are not simple temporal 
phases: they collaborate in order to identify the requirements derived from the objec- 
tives of the Task to be performed (1); Realisation and Technology Provision collaborate 
in order to provide Task performers with a method to carry out this task (2). Install cor- 
responds to all preparative actions taking place in the organisation before the applica- 
tion of the method by commencement of the enactment. Feedback corresponds to 
information on performance and state transmitted from Enactment to Task Analysis. 
More precisely, the four behaviour domains of the PRM can be viewed as refinements 
of the “Generic” level in Figure 4.2: 

• deciding what to do: 

Task Analysis: Perceiving the state of the real-world, and the real-world proc- 
ess, and deciding upon certain desired goals. The result of Task 
Analysis is thus a set of pragmatic objectives which the Realisation 
activity can realistically implement. If Realisation activity is not able 
to establish a method to reach these objectives, a dialogue with Task 
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Analysis is needed regarding the practicability and risk of failure of 
the solution. 

In addition, feedback from Enactment should be carefully analysed 
to determine the inconsistency between the task and its associated 
method as well as between real work and model enactment. 

• devise some course of action: 

Realisation: Realisation is the assembling together of all things that are neces- 
sary to carry out the activity which is necessary to solve the problem, 
and is of course knowledge, methods, tools, resources, and so on. 
This information and resources are brought together in an environ- 
ment where real-world activity takes place. The final activity in this 
domain is installation of the model and, if necessary, the infrastruc- 
ture into the real-world such that the process can be initiated and 
enacted with human participants. 

Install is the transformation of a real world without the process, to a 
world with participants following process behaviour. In pragmatic 
terms this refers to the installation of the process support system, 
incorporating a process model, which will enact the method in an 
organisational environment, and the training of staff to follow the 
specific process. 

Technology Provision: Technology Provision is an activity responsible for 
acquiring and maintaining knowledge of method for problem-solv- 
ing (see Section 4.3.5). It furnishes a Method^ to carry out the asso- 
ciated task. This can be done by simple adaptation of an existing 
method or by creation of a new method from scratch. There is further 
discussion of this in Section 4.4.2. 

• carrying out this action: 

Enactment: This is the process activity which will satisfy the objectives for- 
mulated in Task Analysis. Information relating to process perform- 
ance is fed back to the Task Analysis activity for an assessment to be 
made as to the likelihood that objectives may in fact be reached. 

Obviously the meta-process described by PRM is not a simple one-way process. Ade- 
quacy between the method and the requirements as well as negotiation of objectives 
with respect to feasibility constraints should also be taken in account (the meta-process 
feedback reflect this kind of situations). 

Another important observation is that it provides the expressive power needed to 
address real-world complexity: each of the three components (Task Analysis, Realisa- 
tion and Technology Provision) can use the template of the PRM itself for deeper spe- 
cialisation. That is, each domain can itself be a process which is supported by a PRM. 
For example. Task Analysis can describe a PRM itself (with the objective of, say. 



3. The proper noun refers to a selected process model (generic, or fragment) which, if adapted 
through specialisation, and then enacted, will satisfy the stated objectives. 
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“determining an objective”) and the Method for this will become manifest in its enact- 
ment. Its performance furnishes the needed objectives. 

The PRM as a particular implementation of a MPM should respect the three proper- 
ties identified in Section 4.3. 

4.4.2 Method Specialisation 

The basic PRM concept becomes of practical significance when consideration is given 
to its adaptation to particular situations. In response to a particular set of requirements 
from Realisation, Technology may or may not he able to furnish an appropriate Method. 
If it cannot, it may refine itself into a PRM, and furnish as its objective the provision of 
an abstract process model (development of a Method) to determine the needed Method. 
This specialisation can continue until the specific Method, as defined for the particular 
working environment, is arrived at. The number of iterations does of course depend on 
the original objective and the nature of the environment. 




Figure 4.4 Method Specialisation 

In Figure 4.4 we give an example of a single specialisation of Technology Provision 
to a PRM responsible for implementing the method, the enaction of which fulfils the 
objectives of Task Analysis. T. Realisation analyses method objectives and derives 
method requirements. These requirements are used by the Experience Provision to 
browse existing experience base in order to provide a template method to be adapted for 
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the purpose. T.Realisation specialises the template Method into an enactable process 
model which is installed in an appropriate environment. Enaction of Method Implemen- 
tation provides the actual Method (as a process model) which is then made available to 
Technology Provision, and then to Realisation for adaptation into an enactable process 
model for fulfilling the originally specified objectives. 



4.4.3 Task Decomposition 





Figure 4.5 Task Decomposition 

It may not be possible to furnish a method which is fully defined. For example, the 
knowledge needed to define a part of the method may only be available during the cur- 
rency of the project. Therefore that part can only be defined during enaction. 

After specialising, the Method might consist, to a greater or lesser extent, of sub-task 
objectives linked together in some way by fully defined activities. These objectives can 
in turn be associated with another Method (the pair <task objective, method> is well- 
defined) using a PRM. The method for addressing each task objective is determined by 
enaction of the PRM, and the task objectives are in turn satisfied by enaction of this 
Method. Thus, Enactment implements Task Decomposition. 

In the example given in Figure 4.5 one deals with an abstract task. After Task Anal- 
ysis, the outcome objectives are treated by Realisation to extract Requirements which 
are used by Technology Provision. The Method provided (maybe after Method Special- 
isation) is installed. The enactment of the task leads to n sub-tasks, and use of specific 
PRMs for each of them allows the sub-task objectives to be achieved. 
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The ability of the PRM to refine abstract tasks to more concrete ones in a reflexive 
way is an important property in order to address complex real-world problems. 

4.4.4 Consistency Management 

The relationship between the process model PM and the real world P has been described 
in Section 4.1 with reference to Figure 4.1. This concept is extended in Figure 4.6, in 
that the process model PM can in fact be a PRM which incorporates its own enacting 
process model. The PRM components (Task Analysis, Realisation and Technology Pro- 
vision) could be themselves PRMs with template and enactable process models, and 
enacting instances. All enacting instances interact with reality P. 




Figure 4.6 The Relationship between Reality and the PRM 

There is interaction between the real world and the enactment taking place in Task 
Analysis, Realisation and Technology Provision as well as the enactment of the opera- 
tional process in Enactment. This interaction is of three kinds; 1) Initially, the adapta- 
tion of the real world P as staff learn how to interact with the system, 2) Normal 
provision of input and receipt of outputs by human agents performing activities sup- 
ported by the enactment, and 3) The tensions and mis-match between the actual process 
performance in P, and the enactment following the process model. These latter are of 
particular interest, and may be caused by; 

• poor design of the process which is supported by the PSE, 

• the skills of the participants not being as anticipated, 

• incomplete definition of the process supported by the PSE, 

• requirements of the products having been changed. 

If the process is to remain effective, the symptoms of these tensions have to be iden- 
tified, highlighted for action, and appropriate measures taken by Task Analysis. 









4.5 Validation of the PRM with Respect to Requirements 73 



The reference model so far described goes part way to addressing the set of Require- 
ments which were described in Section 4.2. PRM will also be the template for special- 
isation into any of the existing definitions of the meta-process such as QIP or PRISM 
(see Section 4.6), as well as CMM (see Section 4.7). 

4.5 Validation of the PRM with Respect to Requirements 

This validation is carried out by comparing the model PRM described in Section 4.4 
with the requirements in Section 4.2. 

• Simplicity and Genericity: Particular attention has been paid to developing the PRM 

from domain-independent origins. The ability to address the real-world issues arises 
from its properties of reflexion, inheritance and specialisation. By focusing on 
behaviour only, a very high level model is obtained. 

• Extensibility: This property is not specifically addressed by the formalism, but there 

is nothing in the formalism to impede this: it is reflected in the features of the imple- 
mentation. 

• Flexibility: A) There is no constraint on the implementation domain of the change 

control mechanism: it can be applied just as easily to single person activities as to 
group or organisation activities. B) All change is viewed simply as a difference in 
state to be corrected by a process. C) The model does not place any constraint over 
the way that a particular change is implemented. 

• Robustness: The PRM may be fully defined although the process which is to be sup- 

ported is not itself defined. The definition can take place during execution of the 
process. 

• Interface Management: There is no facility in this model to address this issue. The 

only way is to give the support environment full possession of the screen, and to 
monitor the usage of tools, and thus deduce departures from the process definition. 

• Integration: There is nothing in the formalism to either facilitate or inhibit this prop- 

erty. 

• User support: There is nothing in the formalism to either facilitate or inhibit this 

property. 

• Economic benefit: This can only be evaluated in the context of a real-world applica- 

tion. 

• Strategy: There is nothing in the model to ensure compliance with globally specified 

requirements. 

• Implementable: A small scale and simple model has been implemented in Process- 
Wise Integrator. 

• Enactable: This has been confirmed by stepping through the model in a simulated 

work environment. 
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4.6 Empirical Justification of PRM 



4.6.1 Introduction 

The principal purpose of this section is to verify by practical implementation that the 
PRM covers most (if not all) concepts addressed by some widely accepted existing 
meta-process presented in Section 4.1.3. These meta-process are: QIP, PRISM and the 
“Process life-cycle”. 

4.6.2 The Customisation of PRM as QIP 

The Quality Improvement Paradigm was developed within the TAME-project (Tailor- 
ing A Measurement Environment) at the University of Maryland [BasiSS]. QIP is a 
framework which allows for the improvement of processes by packaged experience 
from former projects by the use of the integrated Experience Factory [Basi93]. 

The Experience Eactory provides an organisational structure which consists of two 
parts: the project organisation which includes all activities for the local adaptation of 
the “experience models” and performance of the software development processes; and 
the experience factory organisation which aims at controlling and continuously improv- 
ing the development processes by means of accumulating evaluated experiences from 
projects. There is thus a double lop of learning: within the projects and within the organ- 
isation. 

In Eigure 4.7, we show how the organisation level of the QIP can be mapped into 
PRM concepts. The project level can also be described using PRM in a very similar 
way. The QIP steps can be mapped into PRM concepts as follows: 

During the “Characterise” step of Task Analysis, project characteristics and specifics 
must be understood in order to identify a set of well defined improvement objectives. 

In the “Set Goals” step of Realisation, project and quality improvement goals are 
identified and stated in an operational way. In this step the software project will nego- 
tiate and commit to global objectives as stated in Task Analysis. The quality goals must 
be “operationalised” and quantified in order to become measurable. The final task is to 
make the concerned persons in the project understand and agree with the project goals. 

In the “Choose Models” step, based on the results from the previous steps, the soft- 
ware project must make a commitment to the process models to be used. QIP proposes 
for this step an impact analysis to determine the impact on reliability, productivity and 
cycle time when the process model is changed. The PRM’s Technology Provision pro- 
vides browsing facilities on the process model data and experience base to identify the 
optimal process model according to the software project characteristics. The selected 
process model is then tailored (in the Realisation part of “Choose Models”) for direct 
use in the software project. 

The “Perform Project” step matches the PPM’ s Enactment activities. The main focus 
during this step is on developing software. However, measurements are continuously 
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Figure 4.7 PRM customised as QIP 

collected in order to monitor and control the project’s performance. Other tasks are: 
drive the usage of the models and reinforce the commitment to make the people use the 
models as planned. The data from the measurements will be saved as the execution his- 
tory of the project. As mentioned earlier, change in the instantiated project can be 
achieved by structuring the project process model in terms of a PRM. 

The “Analyse” step is part of the PRM’s Task Analysis. The analysis of the execution 
history, with help from key personnel from the project, will gather experience from the 
software project’s execution. The analysis of the results should be made with respect to 
the pre-defined project goals and improvement objectives. 

When finishing the project level process we wish to make the software project’s expe- 
rience reusable in future projects. Experiences from using the models and any improve- 
ment suggestions should be reported during the “Package” step. The process models 
might have to be updated and finalised. All important experience “packets” should be 
saved in the experience base, thus models for future projects or project steps can be 
obtained by searching the experience base during Technology Provision activity. 
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4.6.3 The Customisation of PRM as PRISM 

As presented in the introduction, Prism is a process-oriented environment supporting 
methodical development, instantiation and execution of software process models 
through a three-phase model (see Section 4.1.3). The three phases are; Simulation, 
Instantiation and Operation. In the simulation phase, a (part of a) generic software proc- 
ess model is constructed. A generic model is not constrained hy parameters such as 
company resources and is based on the user and project requirements documents. This 
model is then tailored according to the provisions of the software developer and the 
needs of the software project. Simulation shows the need to re-model and re-tailor the 
software process as process designers get some feel from the dynamic behaviour of the 
process model. This phase constitutes the nine steps of the Prism methodology (see Fig- 
ure 4.8). The similarities with the PRM methodology are straightforward; During Real- 
isation, ground work done by the customer and the software developer should provide 
much of the informations needed by the process modellers. The user requirements and 
project requirements documents are driven by constraints and objectives coming from 
Task Analysis. 

After Requirements validation from Review Requirements (step 2), the suitable proc- 
ess model for the project must be built. This can be done either by creating a model from 
scratch or by combination of existing process fragments. In both cases a PRM refine- 
ment of Technology provision will provide the needed abstract process model. This will 
be done in Method Implementation (when executing steps 3, 4 and 5). After the generic 
process model construction, step 6 identifies if tailoring is necessary according the 
actual project’s context. If so. Realisation will execute the tailoring process; analyse 
and classify tailoring to be done (step 7), tailor and test the model (step 8) and, request 
for resources reservation (step 9). 

During the Instantiation phase resources such as tools, people, activities, objects, con- 
straints, conditions, relationships, etc., get assigned to the software process model. 

Finally, during the Operation phase the process model instance is enacted in parallel 
with the real process performance. In addition, incremental collection of prescribed data 
by process monitoring tools, validation and analysis of such data and other process 
management activities as well as improvement recommendations for future projects are 
typical Task Analysis concerns. 



4.6.4 The Customisation of PRM as “Process Life-cycle” 

The Six Phase Meta-Process is another more recent meta-process which is described in 
some detail in Chapter 3. Adopting a PRM view, these steps can be naturally mapped 
into PRM concepts as follows; 

The process elicitation and requirement specification (MP-1) analysis elaborates a set 
of overall goals which should be addressed by the process design. The resulting require- 
ments specify (part of) the features and properties that the process has to offer. This step 
is covered by both PRM’s Task Analysis and Realisation. 
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Figure 4.8 PRM customised as PRISM 

Process analysis and design (MP-2 and MP-3) considers these requirements in order 
to provide the design specifications of the process. Design specifications might affect 
different parts of the process i.e. the production process, the meta-process and/or the 
process support. An important input to this step is the description of the technology that 
has to be integrated and used within the process. The process analysis and design steps 
correspond to PRM’s Technology Provision component. 

The process implementation step (MP-4), contained in PRM’s Realisation compo- 
nent, is responsible for implementing the design specification. This usually leads to 
changes in both process support and real-world process; 

• if the design specification implies the creation/modification of the process support, its 
implementation is accomplished by creating or modifying the process model. In 
addition some possible changes to the process tools may be needed. 
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Figure 4.9 PRM customised as “Six Phase Meta-Process” 

• if the design specification requires the modification/creation of the real-world process 
then this usually involves the definition of specific policies and strategies to manage 
the installation of the new process. 

Process enactment (MP-5) is the executable process model interacting with partici- 
pants and machines to produce the software product. 

Process assessment (MP-6) provides quantitative and qualitative information relating 
to the Enactment of the whole process. Such information is used by the process require- 
ment analysis. By adopting a PRM view, process requirements analysis can be refined 
in two sub-steps: a first step analysing assessment results and building objectives {Task 
Analysis part) and a second step transforming these objectives to requirements {Reali- 
sation part). 



4.6.5 Experience from Empirical Justification 

The experience of specializing PRM to several existing meta-processes leads to the con- 
clusion that there are more complex requirements which will almost inevitably be 
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needed in real applications but which may be to some extent optional. They may be 
required in some circumstances but not in others. These are based on an entire evolution 
cycle consisting of quasi-sequential temporal phases. A completion of a phase will 
invoke the subsequent one, and/or eventually generate a problem report/feedback to the 
arbitrary preceding one; 

1) Specification of goal/objective for change, or the results (e.g., increase of quality 
or productivity) expected to be achieved by performing process evolution. Such an 
objective may come from two sources: either from within the operational process as 
an interpretation and consequence of feedback/metric collected during process per- 
formance, or secondly from manifested external influences on the process, such as a 
change in the market, change in government policy, or simply an idea generated 
within the organisation of a different way to achieve the original goals of the process. 
Thus it can initially be very abstract and will later be specialised and incrementally 
refined to a more obtainable one, e.g. issuing an objective to attain level 3 of CMM 
[Paul93b], which can be refined into specific Key Process Activity goals. 

2) Feasibility analysis of the emerging objective, or predicting the probability of suc- 
cess based on available statistical information and experiences on previous similar 
change processes. In addition, a priori or posteriori impact analysis, i.e., potential 
effects of this change on other, perhaps active, model fragments may be performed 
by, for example, simulation and experimentation. The gathered results of analysis 
should be packaged into an organisational experience or knowledge storage for later 
use. A typical example of this phase is, for example, inspection and analysis of expe- 
riences gained from successful (or unsuccessful) movement to level 3 of CMM 
[Paul93b], and its consequential impacts undertaken by another organisation or 
project. 

3) Acquisition or retrieval of knowledge from, for example, an experience base stor- 
ing previous, valuable knowledge and solutions for similar objectives. The outcome 
of this phase is either an available generic method or process model ready for cus- 
tomizing and installing; or guidelines on how to achieve such knowledge by further 
specializing the initial objective. An example of this activity is to make a query 
against an either internal or external experience base on available method and tech- 
nology to attain level 3 of CMM, and then receive a “Cleanroom” method [Dyer92] 
as a generic process model. 

4) Monitoring and evaluation of collected measures during process performance. 
Those measurements can be assessed and provide a basis to drive a new process evo- 
lution cycle (i.e., from CMM levels 1-5) e.g., due to the fact that the installed process 
is still producing a poor quality product; new procedures are specified. In addition, 
these observations or findings (probably with statistical information to increase their 
credibility) of process performance can also be packaged and lodged in an experi- 
ence/knowledge base facilitating reuse in future projects. 
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4.7 Validation with respect to CMM 

4.7.1 Introduction 

The Capability Maturity Model (CMM) was developed by the SEI to help organisations 
producing software to appraise their ability to perform their software process success- 
fully. CMM delineates the characteristics of a mature, capable software process. The 
progression from an immature, unrepeatable software process to a mature, well-man- 
aged software process also is described in terms of maturity levels in the model. 

CMM is at a level of abstraction that it does not unduly constrain how the software 
process is implemented by an organisation; it simply describes what are the essential 
attributes of a predictable software process. The CMM is not prescriptive; it does not 
tell an organisation exactly how to go about improving its processes. It describes areas 
and activities of an organisation at each maturity level which ought to be addressed to 
achieve the goal of process improvement. 

However, as stated in the “Key Practices of the CMM Version 1.1” document 
[Paul93a], among other features, the CMM can be used for “software process improve- 
ment, in which an organisation plans, develops and implements changes to its software 
process”. In addition, in order to assist the usage of the key practices related to process 
definition, and to define the fundamental concepts of process definition, the conceptual 
Software Process Framework used in the CMM is clearly defined and guidance for 
development and maintenance of processes are proposed. 

The decomposition of improvement activity at each maturity level ranges from 
abstract summaries of each level down to their operational definition in the key prac- 
tices. Each maturity level indicates several key process areas which must be addressed 
to achieve process improvement. Each key process area is organised into five sections 
called common features. The common features specify the key practices that, when col- 
lectively addressed, accomplish the goals of the key process area. 

Thus, CMM can be seen as a Meta-Process methodology proposing guidance for 
process evolution in the same way as Prism or QIP. The major identified activities in 
this conceptual framework are dependent on maturity level, but include: 

• Develop the Organisation’s Standard Software Process (OSSP) 

• Tailor the OSSP 

• Select the Project’s Software Life Cycle 

• Develop the Project’s Defined Software Process 

In CMM, the project’s defined software process is a well-characterised and under- 
stood software process, described in terms of software standards, procedures, tools and 
methods. It is developed by tailoring the OSSP to fit the specific characteristics of the 
project. An organisation’s standard software process is “the operational definition of the 
basic process that guides the establishment of a common software process across the 
software projects in the organisation. It describes the fundamental software process ele- 
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ments that each software project is expected to incorporate into its defined software 
process. It also describes the relationships (e.g ordering and interfaces) between these 
software process elements.” 

4.7.2 Consistency Management 

In the context of CMM, the tension between the real world and the modelled world is 
manifest in that (A) it is accepted in the real world that it is possible to develop “better” 
(i.e. more predictable) software and (B) there is a recognition that one way of achieving 
this is to improve the process by which the software is developed. 

So the inconsistency is between the current quality of software products, and a prag- 
matic appreciation of what ought to be an achievable level of quality. This inconsist- 
ency is “managed”, or “reconciled” by manipulating organisational behaviour, through 
a process model, to bring about products of a quality which was anticipated when the 
development project was started. 

The properties sought are, for example, that the development takes just as long as 
anticipated, at a cost which is near to that budgeted, and of the required quality. The 
assumption is that the knowledge acquired by people in the organisation can be cap- 
tured, analysed, and used to improve the process which guides how projects are planned 
and carried out. 

This inconsistency is then addressed by having in existence a process-improvement- 
process, the first step of which is to determine what is the organisation’s maturity level. 
This then gives an indication of what activities ought to be undertaken as a way of 
expanding qualitative organisational knowledge of software production to facilitate 
evolution of the development processes. 

4.7.3 Task Decomposition View 

Humphrey’s Software Process Maturity Framework [Hump90] can be taken as the 
starting point of the illustration. It provides the structure which establishes the relation 
between the activities of the production process and those of the improvement process. 
This structure is independent of maturity level and so is very useful as a basis for proc- 
ess-improvement process models. 

The framework is illustrated in Figure 4.10. Using Humphrey’s terminology, the 
highest level of control (not to be confused with maturity levels), at the “Organisation” 
level, retains the responsibilities shown which are essentially those of management 
leadership, strategic planning and coordination of communications. The responsibility 
for actually producing the software is delegated through “Overseeing Management” to 
a project-based organisation unit, under the control of Project Management. In the same 
way, the improvement of the software development processes is the responsibility of 
Process Management. Now these are distinct but nevertheless closely integrated con- 
cerns. There is thus a single instance of Process Management, but multiple instances of 
Project Management, one for each software development project. 




82 4 Meta- Process 



Organisation Management 



Making Policies 
Allocating Resources 
Overseeing Management 
Communicating 
Training 



Project Management 

Planning 

Tracking 

Project Controlling 
Sub Contracting 



^Process Management ^ 

Defining (Developing Standards) 

Executing (Developing Methods) 

Analysing (Measures and Uses) 

Controlling (Developing Control Mechanisms), 



Figure 4.10 Organisation model of s/w development company which uses CMM 

Now Process Management activities shown in Figure 4.10 are independent of any 
particular maturity level which the organisation may have attained. However, any more 
detailed description of the activities are maturity-dependent. 

A Level 1 organisation has no means of addressing Process Management concerns. 
The Methods used to develop software are mainly experiential, dependent on knowl- 
edge of team members, voids in knowledge being filled by employing staff with suita- 
ble knowledge, or by guesswork. There is no framework for “learning” from 
experiences: this experience resides in people’s heads. When they move on, they take 
the knowledge with them. 

An organisation at Level 2 has the basic project management expertise upon which 
the software development process can be improved. The concerns are for the institu- 
tionalising of effective management processes, allowing repetition of successful 
instances of the development process. The framework described in Figure 4.10 is thus 
an organisation which has achieved at least level 2. 

Level 3 organisations have established a Software Engineering Process Group 
(already referred to on page) and are in a position to define their standard processes and 
integrate them with the software production processes. 

Improvement from Level 4 is attained by focusing on the addition of comprehensive 
measurement to Level 3 activities, and by addressing software quality management. 

For this example implementation, we will assume that the organisation has achieved 
level 3. The CMM frameworks and descriptions are organisation-independent therefore 
in producing an implementation, certain assumptions have to be made about a fictitious 
organisation 
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4.7.3. 1 Illustrative Model 

In order to illustrate the relevance of the PRM, we model a fictitious organisation which 
has an objective of “Producing quality profitable software” and which has achieved 
level 3, so it has in place a process for process improvement. Now the Method by means 
of which this objective can be achieved consists of Making Policies, Allocating 
Resources, Overseeing Management {of software production is implied). Controlling 
Communications, and Training. This is the first <to,m> tuple (see Section 4.3.4). This 
Method can be refined by considering each of these components in turn as objectives 
and determining the Methods by means of which they can be achieved. Goals can be the 
production of an object, such as a software system, or it can be the achievement of a 
state, such as a certain return on capital. In this case we refine only the Method of imme- 
diate interest, which is that of Overseeing Management. The refinement of the objec- 
tives of this organisation are shown in Figure 4.11. The task objective of the 
organisation is to “Produce quality profitable software”, and this can be achieved by a 
method which requires five sub-tasks: Making Policies, Allocating resources. Oversee- 
ing Management etc. This latter sub-task can itself be achieved by enacting two sub- 
tasks of “Developing Software” and “Improve Software Processes” and so on. In this 
example, the decomposition continues until basic activities that can be performed are 
described. This thread of refinement is given by italics in Figure 4. 1 1. A fuller descrip- 
tion of these activities is provided by Humphrey [Hump90]. 

Our interest is focused on the process of process improvement, so it is only necessary 
to further elaborate the software development process. Note that in the implementation 
of this illustration (see Section 4.8), the development process is explicitly defined, and 
is modified by the improvement process. 

The PRM is used to model this domain, and its initial objectives (provided by Over- 
seeing Management (OvMan)) will be something like “Improve the process of software 
development”. If no method is specified, one such method has to be established by 
enacting a process model to “Establish a process improvement Method”. The following 
section describes exactly how this would be done in a PRM framework. For our imme- 
diate purpose, however, we assume that the Method is in fact CMM. The CMM 
Method, according to Humphreys, involves developing frameworks and standards, 
developing method, development of data gathering techniques and appropriate analysis 
techniques for them, and development and establishment of mechanisms for imple- 
menting process control. This is then the essence of the Method by means of which 
processes can be improved. It is a generic and abstract process model which can be 
adapted for specific needs of the organisation, and its maturity level. In addition to these 
activities, the assessment activity itself would have to be addressed. As mentioned by 
Humphrey, the activity of the Process Management might be carried out by a separate 
group from the software development group, called the Software Engineering Process 
Group (SEPG). The activity areas of Defining, Executing, Analysing and Controlling 
referred to in Eigure 4.10 provide a generic framework suitable for specialising accord- 
ing to the assessed CMM level. Only one of these process areas will be refined for this 
example illustration, that of “Defining”. 
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Figure 4.11 Organisation’s task objective decomposition 

In the Key Practices document [Paul93a], the designated activity is identified through 
the Key Practice Areas (KPA), and, for an organisation at level 3, there are 6: Organi- 
sation Process Focus, Organisation Process Definition, Training Program, Integrated 
Software Management, Software Product Engineering, Intergroup Coordination, and 
Peer Reviews. Each of these in turn identify goals which have to be achieved in order 
to improve the maturity level of the organisation. The KPAs which have been selected 
to be directly addressed in this example are Organisation Process Definition (OPD), and 
Integrated Software Management (ISM). These KPAs were selected as being represent- 
ative, significant, relatively simple to implement, and clearly process-related. The goals 
for OPD are: 

• G1 Develop and Maintain Organisation’s Standard Software Process and 

• G2 Collect and publish usage statistics of OSSP. 

Automated support for achieving these goals can be demonstrated as implemented 
PRMs tasked to Develop the OSSP, and to Maintain the OSSP, thereby ensuring that 
the process of developing the OSSP, and the process of collecting and publishing sta- 
tistics, are subject to feedback monitoring and that they can be changed if their perform- 
ance or quality is falling short of expectation. The implemented model illustrates them 
by means of simple models for ease in implementation. 

And for ISM the goals are: 

• G1 The project’s defined software process is a tailored version of the OSSP, and 
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• G2 The project is planned and managed according to the project’s Defined Software 

Process. 

These ISM goals are not explicitly described in the illustration, but are implemented 
in the enactable model, where the enactment ensures that these goals are met. 

4.7.4 Method Specialisation View 

This discussion will focus on the Method development for the task of “Improving the 
software process’’. This statement of objectives is created at the organisation level of 
Overseeing Management when it is apparent that some positive action is needed within 
the organisation to improve quality by means of process improvement. Any study of the 
software process encompasses all instances of the process; and so activity must take 
place external to normal project activity, by a separate organisation unit. 

Using the PRM structure, this is achieved by creating a new PRM instance with task 
of “Improving the software process”. Certain Methods will be inherited from the parent 
instance (Overseeing Management) which will include organisation strategies, stand- 
ards, and policies; knowledge of corporation-wide databases, and coordinating infor- 
mation (e.g. how projects interact with Allocating Resources). The specialising is 
discussed with reference to Figure 4.4. 

This objective is translated into lower level requirements in Realisation (2) and a 
Method sought for this (3). There will no suitable Method inherited, so one has to be 
determined. This can be done by specialising Technology into a PRM with the objective 
of determining a suitable Method for a Process Improvement Process (PIP) bound to 
T.Task Analysis (3-3A). The Method provided would then be some kind of technology 
selection process (comprising such activities as expand requirements, survey market, 
preliminary selection, specific selection, corporate approval, acquire) which is adapted 
in (5) to the specific PIP requirements. This is then enacted in (6), and the results, the 
selected process improvement process which would be CMM, furnished to Technology 
(7). 

Realisation adapts CMM for this particular organisation and range of software type, 
and the Method is installed in the Organisation as an enactable process model. As out- 
lined in the previous section, this process model would comprise five task areas: 
Assessing, Defining, Executing, Analysing and Controlling. These activities can be 
thought of as sub-task PRMs Tj..Tj^ as shown in Figure 4.5. It may be possible to imple- 
ment Assessing as a physical process model, (e.g. hiring a consultants, or setting up an 
assessment process) but the others cannot be fully defined because the activities are 
dependent on the assessed maturity level (in the example, the assumption was made that 
the maturity level was 3). Thus the initial enactment will comprise only activity needed 
to provide an assessed maturity level. When this is available, the PRMs of Defining etc. 
can be refined by selecting Methods appropriate to this CMM Level, adapting them to 
the specific needs of the organisation, and installing enacting process models which, in 
the case of Defining, will support the development of an OSSP, and the Maintenance of 
the OSSP. 
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The feedback from the enactment to Task Analysis comprises monitoring informa- 
tion as to how well these enactments are progressing, and also coordinating data. For 
example, one of the outputs of Develop OSSP is the OSSP iself, and also details of 
where and how this is made available to the enactments of software development 
projects. 



4.8 Validation of PRM with respect to Implementation 



4.8.1 Introduction 

Two of the requirements for a meta-process model were that the model ought to be 
implementable, and that it should be enactable. The PRM has been validated by defin- 
ing the PRM in Process Management Language, implementing it in the ProcessWise 
Integrator system, specialising it into a model of the Software Process Maturity Frame- 
work, and simulating its enactment. The CMM model used is that already described in 
Section 4.7. 



4.8.2 ProcessWise Integrator 

Processwise Integrator (PWI) [Bruy91] originated in the Alvey IPSE 2.5 project which 
concluded in 1989. ICL subsequently took up the software rights and continued its com- 
mercial exploitation to the present day. Version 2.1 was used in this implementation. 

The system takes the role/activity /interaction notion of defining the mechanism for 
causing transformation events and provides for their enactment in the same context. It 
provides a framework within which tools can be effectively coordinated to service a 
process representation of an information systems development methodology. 

The semantic model is the process programming language (there is no generic model) 
and the application-specific model is defined as a program in that language. 

It is thus a PSEE comprising three elements: the Process Control Manager (PCM), the 
UI Servers, and the Applications Servers. 

The environment holds a model of the process network described in Process Manage- 
ment Language (PML). The language identifies four principal classes: entities 
(records), activities (procedures), roles (the term used here in a very specific way to 
mean encapsulations of data and behaviour) and interactions (corresponding uni-direc- 
tional communications channels). These principal classes, along with numerous primi- 
tive classes, can be used to define the process network. There are three language 
interfaces which together control the evolution of the model: they allow a class defini- 
tion to be compiled into a class value, a new instance of a role class to be created, and 
a role class value to be re-defined. 

The heart of the system is the PCM; that component which identifies, locates, and 
schedules activities which can be executed. It does this by scrutinising each role in turn 
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and examining the guard property of each action which determines when that action is 
allowed to be executed. 

Process participants communicate with roles through the medium of a “pseudo role” 
known as user agent. The User Interface representation is hierarchic, offering, at the 
highest level, an agenda of the roles bound to a participant's user agent. Each of these 
opens into an action agenda allowing selection by the user. 

Application integration comprises the ability to pass data as byte string or object to 
an application running in another environment, to interact with it, and to obtain outputs. 

4.8.3 The Model 

Figure 4.12 illustrates the structure of the implementation. It is separated into three 
domains, according to the SPM Framework, and uses two kinds of objects, defined in 
PWI. These are simple single-threaded roles, and PRMs. A single-threaded role, as 
mentioned above, is a primary component of the Integrator modelling language, and is 
used in this diagram to indicate a physical process model, a “fully defined and enactable 
process definition, not requiring any further specialisation”. Where it is not possible to 
fully define behaviour, an PRM is used. In the implementation, the PRM is represented 
by a network of four PWI roles: one for each of Task Analysis, Realisation, Technol- 
ogy, and Enact. 

4.8.4 The Scenario 

The scenario depicts the improvement of a software production process in an organisa- 
tion. This improvement is brought about through a process development process based 
on the CMM. The specific improvement addressed is to develop an OSSP and to incor- 
porate it into the software production process. This is done by installing a model which 
will allow development of an OSSP, maintain it in a special “library”, and to re-define 
the existing software processes to make use of this OSSP as it becomes available. 

The model is active in the two distinct domains of software development and process 
improvement. The starting point is the component of Organisation Management (OM) 
identified as Overseeing Management. At the outset of the scenario, there is no 
“Improve Process” activity in existence: and Overseeing Management is responsible for 
developing software systems. A trigger labelled “S/W Project” in the Enact role allows 
instances of software development projects to be instantiated. The simple behaviour of 
these processes is to enter text into a text editor to represent Defining the process, and 
also entering text into an editor to represent coding software. The user interface for the 
implementation of OvMan, and the representation of projects, is illustrated in Figure 
4.13. 

In the scenario, the user participating as Overseeing Management now realises that 
the software process needs to be improved, and it should be improved according to 
CMM. A new set of objectives, known as Terms of Reference (ToR) is passed to Real- 
isation, “Use CMM to improve the software process”. The Method to do this is, accord- 
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ing to Humphrey, to set up a Process Managing, tasked to “Improve the process of 
Software Development using CMM”. The Method for achieving this is in fact already 
defined at high level, so the components identified by Humphrey can be represented in 
the model and enacted. These components are Defining, Executing, Analysing, and 
Controlling. In the interests of simplicity, only one of these components is expressed as 
a PRM and developed further: that of “Defining”, the others are represented by simple 
PWI single-threaded roles. See Figure 4.15. As the maturity level at that point is 
unknown, the actual processes associated with these components is unknown. Thus the 
maturity level of the organisation must be assessed (outwith the example), and the result 
is assumed to be level 3. 

The activity appropriate to this level, for the Key Process Area of “Organisation Proc- 
ess Definition” (part of the Definition activity) are Develop and Maintain OSSP, and 
Monitor OSSP usage. This forms the particular Method to address the objectives of 
process improvement in the area of “Defining” and can be structured as simple single 
threaded roles. “Develop OSSP” allows a user to define class definitions for the OSSP 
and to lodge them in the library. A link is provided to OvMan so that the existence of 
the library can be made known to new instances of Projects. Maintain OSSP provides 
definitions “on request” to projects, and records usage for reporting. This demonstrates 
the refinement of objectives necessary to develop an enactable process model. See Fig- 
ure 4.15. 

The OSSP is thus defined, placed in the library, and OvMan notified. The OSSP 
Library is a PWI role containing a data object (String) representing the OSSP, and 
which can furnish copies of this object on request from projects. Comments about the 
OSSP can also be received from projects and this will contribute to the continuing 
development of the OSSP. To bring the OSSP into use in projects, OvMan provides a 
new ToR requiring that new Projects integrate with the OSSP Library and use the 
OSSP. A new project definition, incorporating this, is furnished by Technology, and a 
template change made in Enact, such that all new instances of Software Development 
will automatically access the Library and obtain the current version of the OSSP. Thus 
the level 3 goal of Integrated Software Management can be achieved. 

A new instance of SAV Project is started, and, on invoking “Develop Software” in the 
enacting development process mode, the text editor is not empty, but contains the cur- 
rent OSSP definition, ready for tailoring for the project instance. Deficiencies in the 
OSSP are fed back to the Software Engineering Process Group to modify the OSSP def- 
inition appropriately, and these updated definitions made available to new instances of 
Project Management. 

The Project Management domain is illustrated in Figure 4.14, showing initiation 
actions for both software development processes and for process improvement process. 
In a similar manner, other KPAs for the process improvement process can be imple- 
mented and integrated with the software development process. 
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Figure 4.14 Overseeing Management UI 
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4.9 Conclusion 

In this chapter we have: 

• Described the context in which a meta-process is needed. 

• Identified specific requirements to be addressed by any meta-process. 

• Defined an abstract meta-process model supporting problem-solving methods. 
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• Specialised this model in a Promoter Reference Model based on these requirements. 

• Validated this model with respect to requirements, other meta-processes, and imple- 
mentability. 

4.9.1 Requirements 

It was found that the large majority of requirements were satisfactorily addressed by the 
PRM. A number of them are not directly addressed by the formalism, and they need to 
be satisfied through the selection of a suitable underlying process technology. A few 
can only be validated by a real world implementation of the formalism. 

4.9.2 Managing the Process Improvement Process 

It has been demonstrated that the process improvement process can be expressed as an 
operational process, in exactly the same sense as the software development process 
itself, however with different objectives. Generally, to date, learning has been seen as 
being “packaged” at the end of a software development project and is then used to mod- 
ify the template for the next project. There generally has been little recognition of the 
need for an on-going learning and evolution of the process instance. It could be that this 
has been seen as a concern of management and not a concern of process improvers. We 
hope that this chapter will assist in changing this view. 

4.9.3 Looking at other Meta-Processes 

This work does not set out to critique other meta-processes, and indeed the remarks here 
are confined to those issues which directly relate to their relationship to the PRM. Other 
meta-processes seem to only focus on very specific aspects of the engineering of the 
software development process. Only CMM described the process for improving the 
process definition — the structure for positive evolution, and the means of implement- 
ing it, being provided. However the essential common ground of the compared meta- 
processes were: 

1) All assume that the software development process is fully defined from the outset. 
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2) Most assume that the software development process is unchangeable once it is started 
in a particular project context. 

3) None support the continuous improvement of the process improvement process 
itself. 

4.9.4 Why Use a PRM? 

The proposed PRM is a specialisation of the abstract meta-process model. As such it is 
representative of the level of services such a reference model should provide; 

• It separates out the concerns of process evolution from those of process improvement. 

• It can be specialised into a practical meta-process such as CMM, and in so doing the 

strengths of these other meta-processes can be realised. 

• The meta-process is a model of real world activity, so it can be manipulated, moni- 
tored, and evaluated and evolved just like a production process. 

• It can be implemented, just like an operational process, thus control activities and 

operational activities can be integrated. 

• There is no restriction on the scope and type of change, or how that change is applied 

to the process. The “unit” of change is governed by logical requirements and by the 
underlying technology. 

• It has to cope with incomplete definition (e.g. by simply substituting a reference 

model plus objectives for a full process definition. 

• It has to cope with uncertainty by evolving, and being able to change the direction of 

evolution. 

• PRM can, because of its provision for feedback, structure the evolution of models and 

sub-models. We can thus choose what is to be the “locus” of evolution of the model 
system. 

4.9.5 The Way Forward 

It is highly unlikely that all technologies will be suitable for all processes. It is also clear 
that a complex network of processes is needed to realise organisational objectives. It 
will be necessary for different supporting technologies to somehow be integrated, and 
the formalism of the PRM, or equivalent level of model, may well be the vehicle for 
this. 

A few researchers [Lehm91] have been studying software evolution for many years, 
but it seems only now that the wider software engineering community is beginning to 
appreciate the significance and complexity of the control issues relating to the software 
process, and indeed to processes in general. For a system to be self-regulating, some 
function of the outputs of processes must become some function of the inputs of other 
processes. A mechanism such as PRM is a suitable basis for exploring such concerns. 

Little work has been done, as yet, to identify generic problem-solving methods 
[Poly90]. The MPM and its derived reference models (PRM) focuses attention on the 
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benefits which accrue from maintaining a library of such Methods, and thus, in turn, 
may well help in encouraging the development of a Method library. A key component 
of such a library would be the mechanism whereby Methods were (continuously) 
adapted as a result of experience in project performance. In addition, it will help to 
inject a degree of formality into the process for adapting generic methods into specific 
methods suitable for solving practical problems. 

It is far from easy to express the multi-dimensional complexity in even this “simple” 
model of a meta-process. The graphical methods used here are demonstrably inadequate 
and the hope is that the work will stimulate the development of a suitable process alge- 
braic expression of some kind of PRM meta model. 
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5.1 Basic Components 

A hroad overview of the key components of a PSEE has been provided in Section 1 .6 
(Process-sensitive Software Engineering Environments on page 10). In this chapter we 
will refine the definition of each of these components and discuss different architectural 
alternatives. We start in Section 5.1.1 with the definition of a general reference model 
for architectures of PSEEs to enable us to reason about alternative approaches. The 
components of the proposed reference architecture are motivated by the requirements 
for basic services in a PSEE. 

In Sections 5.1.2 — 5. 1.7 we provide a general description of each service and discuss 
different alternatives for their implementation in existing Promoter systems and others. 

In Section 5.2 we discuss particular requirements and architectural alternatives for 
distributed environments and finally, a concrete example in Section 5.3 describes in 
more detail the architecture and implementation of the distributed PSEE ‘Merlin’ 
[Junk94]. 



5.1.1 A Reference Model for Architectures in PSEEs 

A general reference architecture for PSEEs can be derived by identifying a number of 
required basic services. To begin with, each PSEE needs a dialog management to 
inform users about process information and enable them to perform activities. The task 
of process management is to execute a particular process model and to coordinate con- 
current activities of multiple users. A personal workspace is maintained for each user in 
his/her particular role. It includes all software objects that have to be accessed by this 
particular user/role combination. Software objects and corresponding relations are per- 
sistently stored and have to be efficiently accessible through the PSEE’s repository 
management. 

As represented in Figure 5.1, these basic services are organised as four architectural 
abstraction layers built one on top of another. There are various alternatives as to how 
these services layers may be implemented in components of a particular PSEE. For 
example in one PSEE (e.g. Merlin[Junk94]), workspaces are managed by the process 

J.C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 95-116, 1999. 
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engine only while in others (like COO and Adele) this is part of a sophisticated reposi- 
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Figure 5.1 Reference Architecture for PSEEs 



We can identify a further basic service referred to as communication management 
which is needed to exchange messages (notifications and requests) between the differ- 
ent components of a PSEE and the integrated software development tools. We shall now 
examine each component in some detail. 



5.1.2 Dialog Management 

The dialog management layer encapsulates the user interface of a PSEE. Typically, 
users of a process centred environment can interact with different roles. Generally, we 
can distinguish between the roles of software developers, project managers and process 
engineers. There are different interaction patterns for each of these roles. 
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The knowledge about a software project that has to be maintained by a PSEE typically 
tends to be somewhat extensive. For a single member of the project in the role of a 
developer only a small part of this knowledge is relevant. He/she therefore requires the 
assistance of the PSEE to display all the software artifacts that he/she needs to access 
or is responsible for. This information can be seen as an external representation of a per- 
sonal workspace (see Section 5.1.4). Furthermore, depending on the current state of the 
project, the environment should provide developers with personal agendas which 
include information about all possible activities that can be performed. In order to pro- 
vide the user with a clear overview of more complex workspaces, filters may be applied 
as a means of abstraction. Customised filter settings enable the user to hide less impor- 
tant parts of a workspace representation. 

When an activity is performed whose result influences its own or other workspaces 
(e.g. document states have changed or new documents have been created), these work- 
spaces have to be updated. Such updates should not automatically trigger a refresh of 
the corresponding workspace representations. This is in order to avoid more or less con- 
tinuous refreshes due to activities performed by other users, which would be highly 
‘user-unfriendly’. One solution, applied in Merlin, is to inform a user about a pending 
update of his/her workspace representation by the indication of a special update flag. 
The user can then decide when the changes are to be propagated in his/her workspace. 
Such changes could for example be that a number of new documents are added to the 
workspace or a menu is extended by a further item indicating activities which can be 
performed on the corresponding objects. 

When executing a process, software developers are directly influenced by the con- 
flicts which occur (see Chapter 6). In case of automatic synchronisation, the dialog 
interface must at least report on these conflicts and their consequences. In the case of 
interactive conflict resolution, the developer contributes directly to synchronisation. 

Project managers require tools to instantiate projects, to (re-)assign project members 
with roles and responsibilities and to specify further constraints like milestones and 
deadlines. Not only project managers, but other roles such as developers should also be 
able to get a complete overview of the project including information that is not automat- 
ically displayed within the representation of a single workspace. Such information 
includes for example the project history, defined milestones, responsibilities and roles 
of other developers. Moreover project managers and developers should be able to query 
the environment about the impact of a particular activity. 

Finally, the process engineer requires tools to create new process models and also to 
change existing process models “on the fly’’ using an adequate PML (see Section 3.2 ). 
These tools should provide means to analyse, validate and improve process models. For 
example this may be achieved by the definition of metrics for software process models 
that can be derived from experiences with instantiated projects. 
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5.1.3 Process Management 

The process management component of a PSEE coordinates the different activities of 
multiple developers involved in a software project. For each user involved in a software 
development project it computes his/her specific workspace (see Section 5.1.4) reflect- 
ing the current state of the project. It offers activities on documents according to pre- 
conditions, e.g. the roles which could perform the activity, the responsibilities of a 
person, the corresponding access rights to the appropriate documents, or the depend- 
ency with other documents. 

The process management service should also be able to explain current and previous 
project states on request. For instance the environment should be able to answer user 
inquiries such as ""Why should I code module ml_c?”, "‘Who else is involved in the 
project?”, "‘Who changed the specification for module ml_c?”, or ""What are the time 
constraints for coding ml_cT\ i.e. questions which could be asked by using the inter- 
action facilities of Dialog Management (see Section 5.1.2). 

This service layer can include one central or many distributed Process Engines (see 
Section 5.2) which execute a formal description of the software development process 
which we from now on refer to as the Software Process Program (SPP). An important 
requirement is that SPPs have to be capable of modification during process execution 
because such a process cannot usually be fully determined in advance. An SPP can be 
divided in three layers according to their stability during process execution, namely the 
Cooperation Model and the Process- and Project-Layers. 

i 



frequency 
of changes 




Figure 5.2 Software process program layers 



The Cooperation Model is the most stable part of the SPP. It has to be changed only 
when the user interface paradigm (see Section 5. 1) is changed or new features like con- 
figuration management are added. It provides a predefined set of rules which constitute 
the basis for process execution, i.e. it acts as an inference machine for the description 
of the other two layers. The rules in the Cooperation Model again can be separated 
according to their concerns, e.g. transaction management (see predefined strategies in 
Section 6.3), configuration management, state transitions, and computation of work- 
spaces. 
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The Process-Layer represents the type view of the actual software development 
process. The description in this layer includes for example document types, tool types, 
possible states and state transitions. Changes to the Process-Layer may occur during 
execution of a concrete software development project, because parts of the process 
themselves depend on decisions made during the course of the process e.g. introduction 
of a new test strategy, new test cycles, or the introduction of a new experimental devel- 
opment path. 

Finally, the Project-Layer includes all information that is needed for process instan- 
tiation. The main information that is provided in this layer consists of the names, roles 
and responsibilities of people participating in a project and the types and names of doc- 
uments to be produced. Changes to the Project-Layer may occur frequently because of 
unforeseen events such as sickness of staff, lack of skills, and break-down of machines. 

In existing approaches, the different layers of an SPP may be specified using the same 
or different languages. For example in SPADE one single PML (SLANG) is used to 
specify the Process-Layer and Cooperation Model whilst Merlin uses ESCAPE 
[Junk95] for the specification of the Process-Layer and PROLOG to define the cooper- 
ation model. 

The requirement for changes to an SPP even during the course of process execution 
(“changes on the fly”) requires an interpretative approach as the basis for process exe- 
cution which renders a compiler unusable. 



5.1.4 Workspace Management 

The workspace for a particular user in a particular role at a certain state of the project is 
defined to include only those software objects and relations which are needed in order 
that his or her task might proceed. 

The two basic motivations underlying the innovation of the workspace management 
layer are abstraction and isolation. Workspaces enable users to concentrate on their 
specific task in the project by abstracting away irrelevant information about other parts 
of the project. Eurthermore they contribute to the avoidance of unintended or unauthor- 
ised manipulation of software objects, i.e, to preserve their integrity. 

However strict isolation is not practicable for software processes which are coopera- 
tive by nature. Indeed, developers must both be able to work in isolation when they 
want, and to share objects and to synchronise changes on shared objects in different 
workspaces, generally on their initiative. The cooperation of multiple developers has to 
be coordinated by an advanced transaction mechanism (see Chapter 6). 

There are different alternatives for the implementation of the workspace management 
layer. In many approaches (e.g. COO, ADELE) workspaces are implemented using a 
Base/SubBase architecture which enables nested workspaces. The workspace manager 
then provides capabilities to transfer object copies in a SubBase where developers can 
work in isolation. This basic capability is extended to allow sharing of object modifica- 
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tions. This is specified by the definition of an advanced transaction mechanism (see 
Section 6.2.8. 1 ). 

An alternative implementation (e.g. in Merlin) is to have a common representation for 
shared software objects. In this approach workspaces represent logically different views 
on physically identical objects, corresponding to view mechanisms in database systems. 
Merlin provides an advanced transaction mechanism (see Section 6.4.2) and version 
and configuration management to meet the requirement for isolation. 

5.1.5 Repository Management 

The Repository Management service is responsible for maintaining consistency and 
availability of the information needed by the other PSEE components. Typically, this 
information is concurrently accessed by many different PSEE users. The Repository 
Management has to resolve conflicting accesses and is thus a key component of the 
architecture of a PSEE. 

Evaluations of currently available relational and object-oriented database systems 
show that there is no single commercial system that completely satisfies all PSEE 
Repository Management requirements. Relational DBMSs are a mature technology that 
provides excellent support for querying, distribution, and handling of large amounts of 
data. Moreover, they exhibit very good performance. However, they do not provide suf- 
ficient support for maintaining the kinds of data generated by PSEEs. In contrast, 
object-oriented databases provide excellent support for storing and accessing complex 
and structured objects, but they are a relatively immature technology with poor support 
for querying and distribution. Furthermore, most object-oriented databases are tightly 
coupled to a single programming language, complicating integration with applications 
that are written in a different language. 

In the following we will sketch requirements that have to be fulfilled by a suitable 
Repository Management to build the basis for a PSEE. 

5. 1.5.1 Data Composition and Structure 

A software development project typically generates many different forms of data, as 
illustrated by the following (non-exhaustive) list of common data types; 

• product data, such as source code, configuration management data, documentation, 

executables, test suites, testing results, and simulations. 

• process data, such as an explicit definition of a software process model, process 

enactment state information, data for process analysis and evolution, history data, 
and project management data. 

• organisational data, such as ownership information for various project components, 

roles and responsibilities, and resource management data. 

The boundary between these categories is not always firm. For example, configura- 
tion management data, which is part of the product, includes some part of the history of 
development, which is process data. 
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In each of the three categories, the data items may be composed and structured in var- 
ious ways. As an example consider the document graph in Figure 5.3 that consists of all 
existing documents at a specific state of a project as its nodes, connected by directed 
edges representing inter-document relationships. 

These documents may be stored as complex objects (i.e. objects with multiple 
attributes), composite objects (i.e. objects like modules, libraries, and manuals that con- 
tain other objects), flat files in ASCII or binary, pointer-based data structures (e.g. an 
abstract syntax graph representing a product data object such as a program), contiguous 
data structures (e.g. arrays), or simple basic data units (e.g. integers or strings). 

Moreover, Figure 5.3 shows that data items in a software project are densely intercon- 
nected by a variety of relationships. Examples of relationships include derivation (e.g. 
between an executable object and the source object from which it is compiled), depend- 
ence or inter-object consistency constraints (e.g. between a document and the executa- 
ble that it describes), version order (e.g. between two or more incarnations of an object 
from a history of its modifications), and configuration (e.g. executable objects that are 
linked into the same system). 




Figure 5.3 Data Model: Different Levels of Granularity 



The Repository Management in a PSEE must efficiently handle the storage and 
retrieval of all the data forms. For example, it must implement schemes for disk layout 
and clustering of data that are commonly accessed together, and it must implement 
schemes for transforming data items from their main memory representations to their 
persistent memory representations (and vice versa) whilst maintaining relationship 
information among them. 
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5. 1.5.2 Multi-User Support 

In most projects a number of users work in parallel on different parts of the overall 
project activity. The Repository Management therefore has to he capable of scheduling 
concurrent accesses of multiple users. Conflicts (deadlocks) have to he avoided through 
sophisticated locking strategies or they have to he detected and resolved. 

5. 1.5.3 Efficiency 

The state of the project instance changes whenever a new document is introduced or an 
existing document is deleted, when a document is declared to depend on some other 
document, when a document becomes complete or when it becomes incomplete due to 
a change in some other document on which it depends. Although this list is incomplete, 
it is sufficient to indicate that changes to project states occur frequently, and all cause 
recomputation of the workspaces of all the users who are affected by the changes. This 
computation must be done efficiently, since the user expects his/her workspace to be 
consistent with the current state of the project. 

Furthermore, in order to achieve reasonable response times for syntax directed soft- 
ware development tools an efficient repository is required to store, retrieve and analyse 
fine grained information, e.g. abstract syntax trees or graphs. 

As early as 1987, Bernstein argued that dedicated database systems for software engi- 
neering environments, specialised with respect to functionality and implementation, 
were necessary [Bern87]. He and others [Tayl88] argued that the functionality and effi- 
ciency of standard database systems (in particular relational systems) did not ade- 
quately support the construction of software engineering tools and environments. 

The main reason for the inefficiency of relational systems is that a flat (normalised) 
internal database schema (tuples) does adequately represent high-level data structures 
used in software engineering environments, e.g. relations between complex nodes in 
abstract syntax graphs. This results in expensive transformation procedures between 
both representations. 

Existing approaches prove that object-oriented database systems are a suitable plat- 
form for the implementation of PSEEs. For example Merlin and SPADE both use the 
commercial object management system O 2 [Deux91] while COO uses P-Root [Char93, 
Char94] which is an implementation of PCTE. 

5. 1.5.4 Persistency and Integrity 

Like most software programs, the PSEE may need to be stopped from time to time and 
so it must be able to store the state of the project persistently in order to prepare a restart. 
Even if it is stopped accidentally e.g. by hardware or software failure, it must resume 
with a consistent project state, and such a failure must not result in a significant loss of 
project information. Thus, it is required that the Repository Management preserves 
integrity of any project information, i.e. it ensures that continuation of any operation is 
possible after failure. 
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5. 1.5.5 Distribution 

Multi-user support usually means distribution of the project activities over a number of 
single-user workstations. There are basically two ways to achieve this. The first is to 
have a single server for the repository and to allow distributed access from the user’s 
client workstation. The second way is to distribute transparently the project information 
itself over various repositories that are locally accessible from the user’s workstations. 

With the first approach the single server would certainly become a performance bot- 
tleneck for the whole PSEE, hence this approach seems feasible only for small projects. 
It is, however, worth consideration as many projects are either small or can be split into 
fairly independent sub-projects that are themselves sufficiently small. 

With the second approach, the Repository Management can arrange that parts of the 
project information are represented in local repositories of users which are responsible 
for these parts. The actual distribution of the project information should be transparent 
for the tools that use the repository. It should rather be responsibility of the Repository 
Management to manage physical distribution. This latter approach reduces traffic on the 
communication network as well as the amount of expensive remote access to common 
project information, allowing larger projects to be handled. 

5. 1.5.6 Heterogeneity 

In Section 5.1.6 we proposed an open system architecture for PSEEs which supports the 
integration of different SDTs at various levels of granularity. In order to achieve this the 
underlying repository must be able to maintain different parts of the project information 
in heterogeneous representation. Eor example a module that has been implemented with 
a syntax directed editor is stored as an abstract syntax tree in a non-standard database 
system, while the corresponding error report is an ASCII file in the Unix file system. 

5. 1.5 .7 Evolution 

If there is a feature that is common to every software system, it is this: the system will 
undoubtedly need to evolve. Managing change is primarily a problem of managing 
dependencies. When some part of a system is modified, the dependent parts of the sys- 
tem that are affected by the change must be identified, located, and modified to keep the 
system as a whole consistent. 

There are two kinds of change that a PSEE must manage: changes in the application 
data and changes in the schema (meta data). In the first case, the change is usually local- 
ised. For example, a developer may check out a module, modify it, test the modified 
version, and check it back in again. Change management in this case primarily aims to 
support parallelism and private workspaces, allowing multiple developers to work on 
the same module or related modules simultaneously. Common techniques for the appli- 
cation to use include designing the product as a whole to be made up of small, independ- 
ent components so as to minimise check-out conflicts among developers. The most 
common mechanism with which a PSEE supports simultaneous development is a ver- 
sioning and configuration management facility [Tich94]. The Repository Management 
should be able to support these change management mechanisms. 
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In the second case (schema evolution), a change occurs in the definition of an object’s 
composition, constraints, and methods. That is, there is a change in the object’s type 
definition. A type change has potentially widespread consequences, affecting not only 
all instances of the type but also all programs and other types that use the changed type. 
For example, if an attribute of a type is changed from integer-valued to real-valued, old 
programs (i.e. those written against the integer- valued attribute) may not be compatible 
with new instances of the type (i.e. those created with the real-valued attribute), and new 
programs may not be compatible with old instances of the type. 

The PSEE should provide facilities for schema evolution. Current approaches to the 
problem include those that are based on automatic conversion [Naka91, Barg93], 
delayed or lazy conversion [Ferr94], and versioning of the schema [Skar87]. In the con- 
version approaches, all the type’s instances must be converted (eventually), and all the 
affected programs and methods of other types must be located and recompiled against 
the new type definition. In the versioning approach, each object indicates the schema 
version of which it is an instance, and programs interpret the object according to that 
version of the type. A versioning approach obviates the need to recompile programs that 
use a changed type, but it requires the programs to dynamically bind objects to their 
type definitions rather than statically bind them during compilation. 

5. 1.5.8 Version and Configuration Management 

An analysis of some of the most representative transaction models for PSEE, as 
described in Chapter 6, points out the importance of version management in advanced 
transactions. Thus, the Repository Management layer has to support the management of 
versions of objects and configurations of the set of objects defined in a project. In par- 
ticular, it must enable its clients to derive new versions of (composite) objects, build 
new configurations (by the selection of object versions) and to maintain a version his- 
tory. For example the above mentioned object management system O 2 which is used by 
Merlin and SPADE provides sophisticated versioning mechanisms. 

5. 1.5.9 Flexible Transaction Management 

In traditional data management systems, a transaction is the unit of interaction between 
an application and the system. It consists of a series of accesses to the database together 
with some computation. This kind of data management system preserves data consist- 
ency by guaranteeing the execution atomicity, consistency, isolation, and durability of 
transactions. These properties are often referred to as the ACID properties of transac- 
tions. 

In contrast, the software engineering domain supported by PSEEs is characterised by 
complex, long-lived, and interactive tasks. To manage and reduce the complexity, the 
tasks are usually divided into simpler, parallel subtasks that preserve design modularity. 
The subtasks are distributed together with their associated data among people and 
machines. As a result, the interaction between a software developer and a PSEE is quite 
different to the transactional interaction between the user of a banking application, for 
example, and a database management system. Process knowledge can be used to relax 
serialisability of traditional transaction models as required by software processes. 
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A detailed description of non-standard transaction models in the application domain 
of software engineering is provided in Chapter 6. In any case, there is always a level of 
abstraction at which a process is a serial execution of ACID short-term transactions, so 
the Repository Management layer must provide ACID transactions. 

5.1.5.10 Ad-Hoc Query Facilities 

The Process Managements needs to query the current project information in order to 
extract information about the states of documents upon which the process engine must 
base its decisions. An example of such a query could be; “Select all program modules, 
for which programmer Miller is responsible that are incomplete but whose specifica- 
tions are complete. ” Such queries are not known in advance, so Repository Manage- 
ment has to offer ad-hoc query facilities for use by Process Management. 

5.1.6 Communication Management 

Best user acceptance can be achieved if a PSEE has an open architecture which supports 
different levels of integration. The architecture has to allow a customisable, highly flex- 
ible and extensible environment, otherwise the environment might be regarded as coun- 
ter-productive. This is because; 

• obviously project support has to match the various kinds of projects, 

• an environment should be adaptable to changing needs as a project proceeds, 

• an environment should be partially adaptable to new state-of-the-art technologies 

(exchange of old tools) and 

• it should be possible to add new tools when suitable tools for previously-unsupported 

areas become available. 

An adequate technique to achieve an open environment satisfying the above men- 
tioned requirements is to use a communication framework to integrate different parts of 
the environment rather than compiling all parts of the architecture into a highly inte- 
grated but inflexible monolithic environment. 

An example of an available communication framework which is used in SPADE is 
DEC EUSE^ [DECF91]. It provides a predefined set of messages for tool integration. 
Each integrated tool exports a set of services that can be invoked by other tools upon 
their issuing the appropriate message. Other examples for communication frameworks 
are ToolTalk [Juli94] (used in Merlin), SoftBench BMS [Cag90], Field [Reis90] and 
CORBA [Grou92]. These systems are on different levels of abstraction and they use dif- 
ferent basic techniques, nevertheless they can all be used to build communication man- 
agers in open architectures. 

One major task in such an architecture is to define communication interfaces for its 
components and protocols that define the proper use of the services provided. In order 
to achieve an open architecture, many applications use message-passing oriented com- 
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munication combined with centralised broadcast services. This approach facilitates 
easy substitution of tools. 

Existing message passing protocols typically use the following basic model: mes- 
sages can be divided into requests and notifications. A request is sent to a tool in order 
to use functionality provided by that tool. The requesting component is then waiting for 
a response containing either the result of the requested function or a reason for its fail- 
ure. A notice is sent whenever a tool has performed some activity which might be of 
interest to other components (e.g. creating a new file, or opening another file for edit- 
ing). 

In the case of a process centred environment the simple protocol sketched above has 
to be extended by negotiation functionality: the activity leading up to a notification has 
to be checked for permission to proceed by Process Management before it is performed. 

Communication protocols for requests and notifications are used to preserve consist- 
ency between different representations of data maintained by various components in a 
PSEE. Failures during communication (e.g. due to network errors) can result in incon- 
sistencies between these data representations. The communication protocol has there- 
fore to be defined in such a way that failures can be detected and recovered. 



5.1.7 Tools 

Various tools are used to perform different activities in different phases of the software 
development process. Examples of such software development tools (SDTs) are (graph- 
ical) editors, browser, pager, debugger, compiler and analyzer. Since one of the main 
tasks of a PSEE is the coordination of activities performed by multiple users, the envi- 
ronment has to control invocation and termination of SDTs. 

SDTs can be classified into two categories depending on whether or not their appli- 
cation can have influence on the course of the executed software development process, 
i.e. the state of the current project. An SDT can influence the state of the current project 
if it is able to modify (or even create) documents. These tools we refer to as process rel- 
evant tools (e.g. editors) in contrast to process irrelevant tools (like viewer and 
browser). 

When a process relevant SDT is executed, the changes to the state of the current 
development project have to be determined. For most non-interactive tools which typi- 
cally are executed in batch mode (e.g. compiler, linker, analyzer) this may be done auto- 
matically through examination of exit codes which indicates the result of the performed 
activity. When an interactive SDT is applied the user may have to inform the PSEE 
about the effects of the performed activity on the state of the current project, e.g. a state 
transition for an implementation module from not_yet_implemented to implemented 
after the termination of an edit activity. 

Software engineers who have become accustomed to a specific working environment 
resist changing to a completely new environment, especially before its advantage has 
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been conclusively demonstrated. Thus best user acceptance can be achieved for a PSEE 
if it has an open system architecture which supports integration of existing SDTs. 

So far we have sketched integration of SDTs on the granularity level of documents 
which is rather coarse. A more fine grained granularity of integration is desirable for 
SDTs which work on documents including information that overlaps with parts of the 
project data. This is typically the case for SDTs applied in early phases of the software 
development process. These maintain documents which include information about 
other documents and their relationships. Eor example in a design document each 
described module corresponds to an implementation module in the user’s workspace. 
Interdocument relationships should be controlled even in those SDTs used in later 
phases of a software development process, such as in import/export sections of imple- 
mentation modules. 

Eine grained tool integration facilitates incremental and intertwined software devel- 
opment processes and avoids inconsistencies between representations of documents 
and workspaces with respect to project information. 

Suitable SDTs for fine grained integration have to fulfil special requirements in that 
they have to be syntax directed, i.e. they must work on high-level data structures rather 
than on plain ASCII files. In addition, they have to provide sophisticated communica- 
tion services in order to couple their local process models with the global process model 
of the PSEE. 

Consequently, whenever a user invokes an interaction that modifies inter-document 
information the PSEE is requested whether this interaction conforms to the global proc- 
ess model. If this is the case the modification is performed in the subject document as 
well as in the project information. On the other hand, if the interaction is not allowed an 
error message is displayed to the user. It should be noted that a variety of suitable exist- 
ing SDTs can be integrated in a PSEE by the application of envelopes. An envelope is 
an adapter between different communication interfaces 

There is no doubt that the construction of SDTs with sophisticated functionalities 
such as those described above is a complex task. As a consequence, our current research 
activity is focused on automatic tool generation based on a dedicated high-level tool 
specification language which facilitates abstract description of sophisticated communi- 
cation services [Emme95]. 

5.2 Architectures for Distributed PSEEs 



5.2.1 Determinant Requirements on Architectures for Distributed PSEEs 

Many of the available PSEEs provide a client/server model for process enactment. One 
central process server is used to support many users who are connected to this server. 
This kind of client/server model, provided for Local Area Networks (LANs), will fail 
for distributed software processes for three reasons: 
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• Large scale software processes are not executed in the centralised client/server organ- 

isation as described above. Usually, such projects consist of distributed teams in dif- 
ferent companies. Different companies have different software processes which 
sometimes (e.g. if they involve sensitive information) must not be visible to all other 
companies, teams or persons. Therefore, knowledge about software development in 
such projects is also distributed over the involved companies. Only some small inter- 
faces to exchange documents and process data are required. Referring to this kind of 
software development we can define two requirements which must be supported by 
a distributed PSEE: 

Rl. (Requirement for hierarchical or distributed process organisation). The process 
model itself must be organised in a distributed, hierarchical fashion, i.e. it realises 
a client/server model itself 

R2. (Requirement for distributed process data). In order to avoid misuse of process 
data and documents, both should be stored at the site (company/team) to which 
they belong. This data may be made visible to other sites to allow for necessary 
data exchange. 

• Central process engines serving a few software developers (as their clients) in a LAN 

is considered to be ‘state of the art’. Hundreds or more of software developers, con- 
nected to one central process engine, will suffer performance problems because a lot 
of information has to be exchanged between the clients and the server, i.e. the central 
server becomes the bottleneck. 

R3. (Requirement for distributed process management). Therefore more than one 
process engine must be provided to ensure adequate performance.They may be 
working on a central, their own, or a partially distributed repository. 

• In geographically dispersed teams a further communication aspect arises; that of the 

information exchange via a Wide Area Network (WAN). If any request which 
belongs to some process information has to be exchanged via a WAN, the process 
engine will slow down because of delay times, net problems, etc. 

R4. (Requirement for distributed process engines). Distribution of the process man- 
agement over the sites involved in the software process is therefore required. These 
process engines support either users or further process engines (which may be dis- 
tributed). The data exchange between the process engines is then reduced to the 
cases where data which belong to other machines on other sites are accessed or 
touched. 

5.2.2 Architectural Alternatives for Distributed PSEEs 

The requirements defined in Section 5.2.1 can be mapped on the axes in the Eigure 5.4; 

From this model the following four alternative architectures can be derived which 

more or less meet the requirements defined in Section 5.2.1; 

• Architecture I. Central process engines, central process data. 

• Architecture II. Distributed process engines, central process data. 
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Figure 5.4 Distribution aspects 



• Architecture III. Distributed process engines, partially distributed process data. 

• Architecture IV. Distributed process engines, distributed process data. 

The selected architectures can be described as follows^; 




Figure 5.5 Architecture I 



Architecture I in Figure 5.5 includes a central repository (REP) as a platform for a 
central process engine (PrE) which serves multiple software developers (SD). Although 
this architecture allows for multi-user support, it does not match the requirements for 
distributed process data (R2) and distributed PSEEs (R3, R4). 

Architecture II is currently proposed by most of the PSEEs under development (e.g. 
COO, SPADE) and meets the requirements Rl, R3 and R4. The process management 



2. In the applied graphical notation rectangles are used to represent modules or subsystems and 
directed edges denote used-relationships between modules or subsystems. 
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Figure 5.6 Architecture II 

is distributed (assuming client/server support by the process model), but a central proc- 
ess data base violates requirement R2. In spite of this, the requirements to support a soft- 
ware process in a LAN are fulfilled. What is new in this architecture is that the common 
repository is used by the different process engines to communicate with each other 
about process changes that may cause updates of user environments supported by those 
process engines. This communication is based on a notification mechanism provided by 
the common repository which notifies process engines when changes of the common 
process data occur. 




distributed Repository 



Figure 5.7 Architecture III 



Architecture III meets all requirements defined in Section 5.2.1, because additional 
local process data bases have been added to the process engines. As in architecture II, 
there is a common process data base visible to all process engines which stores common 
process data and serves as the communication platform for the process engines. 

The architecture in Figure 5.8 (Architecture IV) also meets all requirements defined 
in Section 5.2.1. The difference between it and Architecture III is that no global process 
data base is used to exchange data. This is done by introducing a communication link 
between the process engines to enable the exchange of process data. However, this 
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architecture has to handle redundant data (stored in the local process data bases) which 
was held in the common process data base in Architecture III. 




Figure 5.8 Architecture IV 



5.3 Example Architecture: The Distributed PSEE Merlin 

This section describes the architecture of the PSEE Merlin [Junk94] which has been 
developed in Germany at the Universities of Paderbom and Dortmund. The first sub- 
section reflects the architectural alternatives given in the previous section and sketches 
how instances of basic components of the Merlin environment interact. Section 5.3.2 
describes the Merlin architecture in more detail and gives further information on the 
realisation of each component. 



5.3.1 Instance View on the Merlin Architecture 

The Merlin architecture for a distributed PSEE is a combination of Architectures III and 
IV (see Eigure 5.9). Hierarchical client/server architectures can be built using the archi- 
tectures described above by requiring client/server behaviour of the process and distrib- 
uted process engines/data. The leaves of the tree which is described by this hierarchy 
are clients which serve one or more software developers, i.e. their corresponding work- 
ing contexts. This is exactly Architecture I. 

Architectures II, III and IV are able to fulfil the requirement of supporting a PSEE in 
a LAN and a WAN. Note that Architecture II is a special case of Architecture III (with- 
out the local project data bases), but this architecture does not meet the requirement R2. 
The functionality provided by Architectures III and IV is the same; only the perform- 
ance may differ. Eor the Merlin PSEE we chose Architecture III and added communi- 
cation links between the different process engines (see alternative IV), in order to 
increase efficiency of change propagations. 



5.3.2 Type View on the Merlin Architecture 

Eigure 5.10 represents the type view of the Merlin architecture. In this representation 
directed edges denote used-relationships between the different components. The five 
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Figure 5.9 Merlin Architecture (Instance View) 



main subsystems Workspace, Process Management, Tools, Communication axid. Repos- 
itory correspond to basic components introduced in Section 5.1.1. 




Figure 5.10 Merlin Architecture (Type View) 



The following sections describe further details of implementation for each subsystem 
in the Merlin architecture. 
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5.3.2. 1 Subsystem Dialog Management 

For each developer, component Dialog Control controls the invocation and termination 
of all applied tools and the display of his/her specific workspace, a so-called working 
context. It is connected with the corresponding process engine via a communication link 
using the broadcast server. The communication link is used to receive updates of the 
developers’ working context, to exchange menu information and to inform the process 
management about every activity the developer is going to perform. 

Information about the actual working context is maintained as hypertext in compo- 
nent Workspace Representation which encapsulates an attributed graph. In this data 
stmcture documents are represented as nodes while relationships between documents 
are represented as directed edges between nodes. Further information about possible 
activities on specific documents or access rights are stored as node attributes. 

As an example of the visualisation of a working context in Merlin consider Figure 
5.11. The sample working context represents the view of user Miller in his/her current 
role programmer on the information concerning project merlin_demo _project (see the 
top line of the Working Context Window.). It displays the documents to be accessed and 
their interdependencies and the activities that may be or have to be performed on each 
document. 

Documents are represented as rectangles that have context-sensitive menus attached 
which contain all performable activities on the corresponding documents. Inter-docu- 
ment relationships are described by labelled arrows between rectangles. Selection of a 
menu item triggers the execution of an activity and hence the invocation of the corre- 
sponding tool. Possible menu items are displayed in Figure 5.11. where programmer 
Miller has read access to the specification documents ml_spec and m2_spec (by 
ascii _pager and ascii _printer) as well as read/write access to the implementation doc- 
ument ml_c. 

After the execution of a modifying activity the new state of the corresponding docu- 
ment has to be set by the user. This may be done by the application of a selection win- 
dow which offers a list of all possible new states for the document. As an example we 
assume that Miller has selected the activity editor for ml_c. In this case two additional 
windows appear on the screen, one for editing ml_c and the second to select the new 
state. 

In addition, the subsystem Dialog Management provides generic user interface serv- 
ices including various dialog objects which enable interaction between the developer 
and Process Management, e.g. to support the transaction manager by selecting a spe- 
cific transaction type for an activity and interactive resolution of conflicts (see Section 
6.4.2). 

5.3.2.2 Subsystem Tools 

This subsystem includes all kinds of tools integrated in the Merlin PSEE. Highly inte- 
grated SDTs can be generated from specifications [Emme95] or adapted for their appli- 
cation in Merlin by using ToolTalk [Juli94] envelopes. Tools are classified into tool 
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MERLIN WorkingContext 




Figure 5.11 Sample Dialog in Merlin: Activity 

classes corresponding to their application purposes (e.g. ASCII-editors, debugger, 
pager). Each developer can customise his or her workspace to use the tools he/she pre- 
fers. The representation of documents maintained by the different tools varies from 
plain text files stored in the Unix filesystem to abstract syntax graphs stored in non- 
standard database systems like GRAS [LeweSS] or object management systems such as 
GemStone [Bret89] or O 2 [Deux91]. 

Merlin provides a number of tools with special functionality such as Mail and Query. 
The mail tool is used for communication purposes between the different users of the 
PSEE. It supports special features like abstract addressees (e.g. tester of module ml.c) 
and message redirection. 
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The user can retrieve additional information about the process, project history or 
impact analysis using the tool Query. This tool translates user queries into queries that 
can be understood by the reasoning component (subsystem Process Management) and 
transforms answers into a comprehensible format. 

5.3.2.3 Subsystem Process Management 

The process engine (module PE-Interpreter) is implemented as an interpreter for a rule- 
based language similar to PROLOG. For application in a PSEE the language PROLOG 
has been extended by special predicates, e.g. for communication purposes or to main- 
tain persistent process data (rules and facts). 

As depicted in Eigure 5.9 there is a separate instance of a process engine for each Mer- 
lin user. Synchronisation between different process engines is performed via a common 
repository and the notification mechanisms provided by the Merlin communication sub- 
system. 

The Software Process Program is a collection of rules, facts and predicates and is sep- 
arated in three layers as explained in Section 5.1.3. The two subcomponents Transac- 
tion Manager and Version Manager are also implemented in PROLOG rules and 
actually belong to the Cooperation Model of the Software Process Program. Neverthe- 
less, as a key component of the Process Management we decided to bring out their log- 
ical position in the Merlin architecture clearly in Figure 5.10. 

The Reasoning component uses the PE-Interpreter to evaluate impact analysis and 
retrieve information about project history. Information about project history is also 
stored as facts in the Project-Layer of the SPP. 

Specifications of processes in the high level PML ESCAPE [Junk95] are translated 
into executable PROLOG programs by means of the Process Modelling component. 
Furthermore information about concrete projects like responsibilities and roles can be 
modified. 

5.3.2.4 Subsystem Repository 

Merlin uses an heterogeneous, distributed repository to maintain persistent Software 
Process Programs. The object management system O 2 [Deux91] is used to store and 
retrieve all information residing in the Project-Layer. In O 2 rules and facts are distrib- 
uted in so called rule clusters or fact clusters. Such clusters can be dynamically made 
visible or invisible for certain process engines. 

The mechanism for ACID transactions provided by O 2 is used as platform for the 
sophisticated Transaction Manager in Merlin (see Section 6.4.2). Furthermore O 2 pro- 
vides an advanced a flexible mechanism for versioning of complex objects which is 
exploited in the Merlin version and configuration management. The object management 
system O 2 has been used also for implementing the SPADE- 1 prototype. 

Currently, the Unix filesystem is used to store all information in the Process-Layer 
and the Cooperation Model of the Software Process Program. Tools that have been 
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integrated in Merlin use for example the non-standard database system GRAS[Lewe88] 
or GemStone[Bret89] for persistent representation of documents. 

5.3.2.S Subsystem Communication 

Basically, the Communication subsystem includes two components. Messages between 
(distributed) instances of Process Management and Dialog Management components 
are exchanged using the Broadcast Server. The Broadcast Server maintains a list of all 
communication clients which are currently active and redistributes incoming messages 
to all clients of interest. In the existing Merlin prototype the Broadcast Server is imple- 
mented using TCP/IP communication services. There will shortly be an extended 
implementation based on open ToolTalk [Juli94] protocols. 

The Communication Interface component is used by all those other components in the 
Merlin architecture which are designed to exchange messages via the Broadcast Server. 
It provides basic functionality to send and receive synchronous and asynchronous mes- 
sages. 
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6.1 Introduction 

6.1.1 Objective 

Cooperation is “acting together in a coordinated way in the pursuit of shared goals”. 
Cooperation has numerous benefits; efficiency, where cooperation minimises the effort 
required to achieve the goal; enhanced capability, where a group can achieve a goal not 
possible for one person to achieve; synergy, where the cooperating partners can together 
achieve a different order of result from that achievable separately. Cooperation has also 
one main disadvantage; there is always an associated energy and time overhead. 

Current software processes are cooperative and our objective in this chapter is not to 
propose new cooperation patterns. It is, rather, to describe and support current cooper- 
ative software processes, with an emphasis on the problems of consistency and integrity 
maintenance of software artifacts. 

In fact, software artifact consistency and integrity maintenance on the one hand, and 
cooperation support on the other hand, are somewhere antagonistic. Classically, con- 
sistency and correctness are achieved by isolating the processes which execute in par- 
allel (typically, most traditional database transaction protocols imposes isolated 
execution of processes). However, cooperation means that it is beneficial for the people 
involved in the processes which execute in parallel to interact. Thus, a challenge when 
building a PSEE to support software processes is to enable cooperation while continu- 
ing to achieve correctness. 

Three approaches can be considered. A cooperation policy can be based on; 

a) the responsibility of human agents alone, as it is the case in most current software 
development applications, 

b) the knowledge included in the software process model without identifying any spe- 
cific knowledge related to cooperation support. This makes the hypothesis that all the 
interaction cases are forecast. ADELE and SPADE appear in this category. 

c) some predefined strategies, not depending on a particular process and which can be 
reused from one process to another. This is the transaction paradigm as in COO, and 
Merlin for example. 

J.C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 117-164, 1999. 
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In general, a cooperation policy is a combination of these approaches: transactions 
make the hypothesis that processes can be launched at the appropriate time (based on 
some knowledge of the process) and knowledge can be organised in reusable libraries 
(which can be considered as predefined strategies as transaction models are). 

In the rest of this chapter, we illustrate these approaches by means of a common 
example: COO and Merlin are representative of the transaction paradigm, ADELE and 
SPADE of the purely process based approach. This objective is achieved, on the one 
hand by a short description of the architecture of each system considered, and by the 
implementation of the example introduced in the following section (Section 6.1.2) in 
each system. 

6.1.2 An Illustrative Example 

Let us consider a supposed simple software process (see Figure 6.1). The objective of 
the task is to produce the code of a module B which depends on a module A. Module A 
and module B are developed by two groups of people who want to work in synergy. 
This is a very common situation in software processes and that defines a pattern which 
can apply to different artifacts at different levels of a software life cycle. 




Figure 6.1 A simple process 



This process is hierarchically organised. The root process represents the whole proc- 
ess which breaks down into sub-processes. The leaves are atomic processes (which exe- 
cute atomically in isolation), and the upper levels are compound processes. 

The objective of this coding_task process is to “produce the object code for a module 
A and the object code for a module B”. Thus, coding_task splits into two sub-processes: 
produce _object_code (A) and produce_object_code (B). Each sub-process executes as 
a consistent combination of one or several occurrences of edit _interf ace, edit_body and 
comp/te applied to A or B. Each leaf process is an abstraction for read and write oper- 
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ations. Lets now suppose that the body of the module B (B|^) depends on the interface 
of the module A (A;). This can be interpreted as; editJbody(B) is an abstraction for read 
(Ai), and write(Biy). In this context, it is clear that the two operations edit_interface(A) 
and edit_body(B) are concurrent when accessing A; and that the produce_object_code 
(B) sub-process must at least enforce a rule which ensures the body of B (B|^) is edited 
with the final (last) value of the interface of A (A;). This rule describes a part of our 
knowledge about the coding_task process and a correct execution of coding_task is 
always an execution of the six (sub-)processes; edit_interface(A), edit_body(A), 
compile_body(A), edit_interface(B), edit_body(B), compile_body(B), which respects 
the policy (rules) just defined. 

Let us now consider three scenarios on the following pages. 
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Scenario lisa correct execution of codingjtask in which produce_object_code(A ) 
and produce_object_code(B) execute without interaction. The only object in shared by 
the two processes, the interface of A, is accessed first by produce _object_code( A), then 
by produce _object_code(B). Clearly, assuming the atomicity of leaf sub-processes, this 
execution is equivalent to the serial execution of produce_object_code(A ) followed by 
produce_object_code( B ). 



Table 6.1 Scenario 1; correct and without interaction execution of coding_task 

produce object code A produce object code B 

edit_interface(A) 
edit_body(A) 
compile_body(A) 
edit_interface(A) 

edit_interface(B) 

edit_body(A) 
compile_body(A) 
edit_body(A) 
compile_body(A) 

edit_body(B) 
compile_body(B) 
edit_body(B) 
compile_body(B) 
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In contrast, Scenario 2 depicts an execution in which produce_object_code(B) reads 
the interface of A at the same time it is being modified hy produce _object_code( A). In 
fact, produce_object_code(B) sees an intermediate value of produce _object_code(A)\ 
the two processes interact. Clearly, this schedule can be non serialisable. Nevertheless, 
we can verify that this scenario is also correct. This is based on the following reasoning. 
Firstly, proiiMce_o/yecf_coc?efBj reads the final value of the interface of A, since the last 
edit_body(B) appears after the last edit_interface(A). Secondly the last editJbody(B); 
compile _body(B) sequence compensates all the previous ones (in the sense that its 
result is the same as if the previous sequences did not occur). Thus, even if the value of 
the body of B is inconsistent at point 1 because it is based on an intermediate value of 
the interface of A, the final value of the body of B, at point 2 is consistent with module 
A because it is based on the final value of the interface of A. 

Table 6.2 Scenario 2; correct and with interactions execution of coding_task 



produce object code A 


produce object code B 


edit_interface(A) 


edit_interface(B) 




edit_body(B) <- point 1 




compile_body(B) 


edit_body(A) 




compile_body(A) 




edit_interface(A) 




edit_body(A) 




compile_body(A) 




edit_interface(A) 


edit_body(B) 


edit_body(A) 




compile_body(A) 


compile_body(B) <-point 2 
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Scenario 3 demonstrates that some sequences of the same atomic processes can be 
incorrect: the last value of the interface of A read by editJbody(B) is not the final one. 
The interface of A has been changed since the last edition of the body of B. 



Table 6.3 Scenario 3: incorrect execution of coding_task 



produce object code A 


produce object code B 


edit_interface(A) 


edit_interface(B) 




edit_body(B) 




compile_body(B) 


edit_body(A) 




compile_body(A) 




edit_interface(A) 




edit_body(A) 




compile_body(A) 


edit_body(B) 


edit_interface 




edit_body(A) 




compile_body(A) 


compile_body(B) 



We have pointed out two executions of the same process which are both sequences 
of the same atomic activities and which are both correct. However, these schedules are 
not equivalent. The second allows interactions to occur between produce _object_code 
(A) and produce_object_code(B) while the first does not. We think that interactions 
between processes must generally be supported. In fact, interactions between activities 
also imply interactions between people which are generally positive in social processes 
such as software development processes. Nevertheless, it is also clear that in some cases 
interactions can be considered as undesirable, and visibility of intermediate results must 
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be prohibited. This is especially the case when intermediate results are used by proc- 
esses which cannot be easily compensated (as an example, putting an insufficiently 
tested product on the market can have huge consequences). In such case, an isolated 
execution as in Scenario 1 is the most commonly adopted solution. 

This example illustrates a simple case of positive interaction, of cooperation. Others 
are characterised in the rest of this chapter. 

6.1.3 Organisation of the Chapter 

The following section (Section 6.2) makes a survey of traditional and advanced trans- 
action models. It identifies their limits and advantages with regards to our process char- 
acteristics: uncertain duration (from hours to months), uncertain developments (i.e. 
activities that are unpredictable at the beginning), and interaction with other concurrent 
activities. The motive is to introduce the problems related to consistency maintenance 
in general and the basis on which “predefined strategies approaches” are founded. Sec- 
tion 6.3 addresses the issue of how cooperation control impacts the PSEE architecture. 
Section 6.4 describes the current work on the topic in the Promoter Working Group. 
The last section, (Section 6.5) concludes. 



6.2 Moving from Traditional to Advanced Applications 

The definition of transaction for advanced applications changes, mainly due to human- 
interaction. It is transformed from a pre-programmed implementation to a variable 
working session. Accordingly, a fundamental difference from traditional transactions is 
represented by characteristics like non-atomicity and non-isolated execution. 

Before deepening this evolution, we are reminded of the basic properties, called 
ACID, of traditional transactions. [Bern87a] provides a sound introduction to concur- 
rency control and transaction processing. 

6.2.1 ACID Properties 

An important concept for traditional database transactions is the ACID properties 
(Atomicity, Consistency, Isolation and Durability). 

Atomicity: A transaction is an atomic unit of processing. It either executes in its entirety 
or not at all. This is the “all or nothing” law. 

Consistency : A transaction execution results in a database state that satisfies all the con- 
sistency constraints of the application; that is, if the program has functioned accord- 
ing to its specification'. 

Isolation: A transaction should not make its modification visible to other transactions 
until it is committed, i.e, until its effects have been permanently recorded in the data- 
base. 



1. This assumes the specification is correct and complete. 
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Durability: Once a transaction results in a new database, the performed modification 
must never be lost because of system failure. 

These properties are too strict for software processes. This is especially due to the ato- 
micity and isolation properties. 



6.2.2 From ACID to Non-ACID 

Atomicity and Isolation have two implications. First, it limits cooperation: if requested 
data is kept private or locked by one long transaction until it terminates, other concur- 
rently running transactions will be forced to wait for its termination. Thus, it prevents 
data from being freely exchanged among humans, and made accessible as soon as pos- 
sible. 

Second, if a transaction fails^, the work done inside its context should be undone. A 
lot of work could be thrown away, although not influenced by the causes of failure. Fur- 
ther, if cooperation took place with the failed transaction, transactions cooperating with 
it could possibly be aborted in cascade. Thus, a requirement for long transactions allow- 
ing cooperation is to separate work done privately from work done cooperatively (and 
thus influenced) by many transactions. In fact, in the case of failure, it should be possi- 
ble to un-do one transaction’s (private) work at a fine-grained level, and to restart it, 
without causing related, but not affected, cooperators to clash. 



6.2.3 From Flat to Nested 

Flat transactions are allowed to execute atomic data accesses. Nested transactions may 
also start new (sub-) transactions, that is decompose themselves into transaction hierar- 
chies. Nested transaction are well adapted to hierarchically organised processes such as 
software processes. 



6.2.4 From Closed to Open 

Nested transactions in general refers to closed-nested transactions, as opposed to open 
nested transactions. Closed-nested transactions have been mainly introduced to limit 
the impact of a logical or physical failure to a sub-transaction. Atomicity and isolation 
of (sub-)transaction executions is preserved. Opened-nested transactions relax isolation 
and can relax atomicity by allowing partial results to be observed outside the transaction 
before its completion. To maintain consistency of execution, although the isolation 
principle is not preserved, the semantics of high-level operations are exploited. On 
account if the long duration, uncertainty and interactive nature of our processes, open- 
ness is preferred. 



2. Failure may be either user-driven (e.g., certain activity is cancelled from a project), or process- 
driven (e.g., due to conflicts with other activities). 
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6.2.5 Hierarchical versus Layered 

When a transaction splits into sub-transactions, a question arises: do we need to pre- 
serve consistency globally or locally? Can we have one scheduler per (sub-)transaction 
or must we have a global scheduler for all the nested transactions? Theory demonstrates 
that we can have one global scheduler or, with some restrictions on the organisation of 
the transaction, one scheduler per level. In the first case, we refer to (vertical) hierar- 
chical transaction breakdown, in the second case, we refer to (horizontal) layered trans- 
action management. We think that layered transactions are too rigid because of the 
dynamism of our processes. 



6.2.6 Homogeneous versus Heterogeneous 

Homogeneity refers to the way transactions are scheduled, or more generally, how 
transaction behaviour is managed. A global scheduler can either integrate local sched- 
ulers which implement the same protocol, or schedulers which implement different pro- 
tocols. In the first case, the scheduler is homogeneous, in the second case, it is 
heterogeneous. It must be also noted that not all combinations are possible. Clearly, in 
the case of a layered transaction, different protocols can be implemented at different 
levels without restriction. In the case of one heterogeneous global protocol, interfer- 
ences between sub-protocols must be managed. 



6.2.7 From Transient to Persistent 

Persistence is the ability of objects to persist through different program invocations 
[Atki96]. Accordingly, objects may be either transient or persistent. Transient objects 
are only valid inside the program scope, and they are lost once the program terminates. 
Persistent objects are stored outside the program and survive updates. In other words, 
they persist across program execution, system crashes, and even media crashes. These 
objects are the recoverable data of the management system, and are shared, accessed 
and updated across programs. 

Traditionally, transaction stmctures are in main memory, i.e., they are not persistent. 
Thus, if a failure occurs, the transaction rolls back. This is not acceptable for long term 
transactions: transaction structures must persist in such a way that, in case of a failure, 
the process engine is able to restart from a state close to the failure state. 



6.2.8 Available Advanced Transaction Models 

This section reviews several representative advanced transaction models: closed nested 
transactions, split transactions, cooperative transactions, layered transactions, and the 
S -transaction model. This is done through the definition of a transaction model in terms 
of its three components: structure, primitives and protocol. 
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6.2.8. 1 Advanced Transaction Models: Classification 

To reason about the transaction requirements for a particular application class, 
advanced transaction models are first analysed at the design level. A transaction model 
is a representation of the elements relevant for transaction definition and execution. It 
consists of three main parts; 

Transaction structure; it defines how single transaction types are defined, and how 
sets of transactions are syntactically related together. Transactions may be ACID 
(i.e., atomic units that fulfil ACIDity); Compensating (i.e., transactions that can 
semantically undo the effects of an associated transaction after this has been commit- 
ted [Wach92]); Contingent (i.e., alternative transactions that are executed if a given 
transaction fails); or Vital (i.e., transactions whose termination influences the termi- 
nation of the related transaction. For example, if a sub-transaction has a vital relation 
with the parent, then its abort causes the parent abort). 

Transaction primitives; which are the basic operations, i.e., to manage internal behav- 
iour (e.g., creation, execution, termination), and external behaviour with respect to 
other cooperating transactions (e.g., communication, data transfer, data access syn- 
chronisation). 

Transaction protocol; which is the behaviour of a set of transactions viewed as a glo- 
bal unit that execute concurrently and need to cooperate. Related issues are concur- 
rency control and recovery. 

In summary, the transaction structure reflects the organisation/work breakdown, 
while a transaction protocol defines how transactions can interact, and how they can 
access data. 

6.2.5.2 Closed Nested Transactions 

The enhancement of flat to nested transactions introduces two main important advan- 
tages [Moss85]; 

1) execution parallelism internal to a non-leaf transaction (intra-parallelism), and 

2) finer control over failures and errors, thus achieving recovery guided by semantic 
information. 

Transaction Structure 

Transactions can have infinite levels of nesting. The semantics is that of decomposing 
a transaction into a number of sub-transactions, the overall structure being a tree (or 
hierarchy). 

Transaction Primitives 

Apart from traditional atomic operations for transaction creation and termination 
(Commit and Abort), and for data access (Read, Write, Update and Creation), transac- 
tions are allowed to invoke atomic transactions as well. By invoking a transaction from 
within its scope, a sub-transaction is created and the nesting is implicitly achieved. 



Transaction Protocol 
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Several protocols have been modelled to achieve transaction synchronisation. The 
way transactions declare their work intentions (i.e., how they reserve data) differs from 
model to model. Their suitability depends on the kind of application the model is used 
for. The main techniques are based on locking and time-stamps. 

Furthermore, locking can be exclusive or refined into read and write mode. In both 
cases, to preserve isolation, the parent inherits the lock mode (at child commit) and 
stores it in its own place-holder. The effect is to grant data access only to descendants: 
if a transaction tries to lock some data, it is allowed to do so only if either the data has 
no lock at all (i.e., is free) or its parent already has the lock in its place-holder. 

If a child transaction aborts, locks are simply released and not inherited by the parent 
as no effects on data persist. 

6.2.S.3 Split Transactions 

Split transactions propose a solution for restructuring in-progress transactions, still pre- 
serving consistent concurrent data access. Split transactions support open-ended activ- 
ities like CAD/CAM projects and software development. A practical example of this 
model’s usage is in user-controlled processes, where users determine what database 
operations to perform dynamically, during execution. In real applications, split transac- 
tions are a natural means of committing some work early or dividing on-going work 
among several co-workers. Further, a split transaction can hand over results for a co- 
worker to integrate into his/her own ongoing task. 

Advantages of this model are: 

a) adapting recovery effort: because split transactions can abort without affecting the 

result of the original (splitting) transaction. 

b) reducing isolation: by committing part of a transaction, resources can be released 

whenever needed, thus achieving higher concurrency. 

Transaction structure 

The original (simple) model assumes transactions as composed of a sequence of oper- 
ations, similar to ACID transactions, i.e., abstracted into Read and Write operations, 
starting with Begin, and ending with either Abort or Commit. 

To include parallelism, the model has been extended with nesting, where a set of top- 
level transactions may be executed concurrently. Later on, super-transactions have been 
included (see [Hard93]): a super-transaction includes two or more independent transac- 
tions, and makes them appear atomic to transactions outside the super-transaction itself. 

Transaction primitives 

Primitives peculiar to split transactions are Split and Join [Kais92]. The Split opera- 
tion divides the on-going transaction into two (or more) serialisable new transactions, 
and assigns its resources among the resulting transactions. Thus, Split and Begin repre- 
sent the set of initiation operations by means. The Join operation merges two or more 
transactions that are serialisable with respect to each other, into a single transaction as 
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if they had always been part of the same transaction, and all their work is now commit- 
ted or aborted together. Thus, Join, Abort and Commit represent the set of termination 
operations. 

Transaction protocol 

The major purpose of splitting is to commit one of the resulting transactions to reveal 
useful results from the original transaction. An example is shown in Figure 6.2, where 
transaction T initiates a Split operation that results in two new transactions (A and B) 
replacing T. 



( T ) 

Split-in Split-in 




QD— -KIZ) 



Pre-order 



Figure 6.2 Split transaction T into transactions A and B 



Of course, when splitting, consistency on data must be preserved. For instance, sup- 
posing in the example that transaction A and B fulfil properties: 

WriteSet{A) n WriteSet(B) c WriteLast{B) 

ReadSet(A) n WriteSet(B) = 0 

WriteSet{A) C\ReadSet{B) = SharedSet 



B must be executed after A, as the work context of B depends on results in the work 
context of A. In other words, for property 1 , any data written by both A and B is written 
last by B (i.e. A cannot overwrite B’s output), for property 2, A does not have visibility 
on data which is changed by B (and thus does not depend on B), while for property 3, 
B has visibility of data changed by A. 

To allow A and B to be independent, the following properties should hold: 
WriteSet(A) n WriteSet(B) = 0 

ReadSet(A) n WriteSet{B) = 0 
WriteSet(A) ReadSet(B) = 0 
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6.2.S.4 Cooperative Transactions 

The concept of cooperative transaction was introduced in [Nodi92] to support a higher 
level cooperation than in traditional transaction models. This model substitutes the 
notion of correctness defined by serialisability, with a notion of user-defined correct- 
ness by means of Finite State Automata. In this way, cooperative transactions can use 
different correctness criteria (the most suited for their own purposes). Further, isolation 
is not required, and hierarchy allows both close cooperation to take place, and easier 
management for long-lived transactions. 

Transaction structure 

Transactions are organised in a rooted hierarchy, where internal nodes represent 
groups of transactions that cooperate to perform a single task, while external (leaf) 
nodes are associated with individual designers. A transaction group (TG) is thus a col- 
lection of cooperative transactions that cooperate to perform a specific task, or other 
TGs. It can be seen as the abstraction of a task, undertaken by its members. With this 
viewpoint, TGs are spheres of control over children. A cooperative transaction (CT) is 
a program that issues a stream of operations to the underlying database. It can be 
defined as the sphere of control over actions on data. 

Transaction primitives 

In terms of primitives this model does not define new constructs (using the traditional 
begin and commit/abort), but define a particular way in which they are managed. In fact, 
primitives define atomic actions on a single object by a single CT member of a TG. Ato- 
micity in this case means that primitives cannot invoke other primitives, and are defined 
either on objects (e.g.. Read or Write), or on their interface. 

During its lifetime, a CT issues primitives on objects in its TG. There primitives are 
executed by the TG once it determines that they conform to its correctness specification. 
If not, primitives are rejected, i.e., individually aborted. This means that primitives are 
submitted to the TG which uses the correctness criteria to abort those which are not 
valid and accept those which are valid. 

Transaction protocol 

Transaction behaviour is modelled by a correctness specification (or criteria) of TGs 
on each single CT. 

A correctness specification is defined in terms of: 

a) conflicts, identifying primitives that are not allowed to execute concurrently, 

b) patterns, defining sequences of primitives that must occur, 

c) triggers, taking actions when a request by a CT begins or terminates. 

A TG specification describes its valid history; the allowed sequence of primitive 
invocations issued by its member CTs. Thus a TG identifies the sphere of cooperation 
that takes place among its component CTs. Thus, correctness is defined in a top-down 
fashion, pertaining the TG members. Moreover, a TG history is correct if it satisfies its 
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own criteria, and the histories of its member CTs are correct, i.e., if it conforms to all 
the patterns and contains no conflicts. 

A certain transaction protocol is defined for each TG, by the relative specification. 
Two alternative ways can be used to enforce a protocol; optimistic, where CTs issue 
their entire sequence of primitives and thereafter this is checked against the protocol, or 
on-line, where each primitive is controlled when issued. The latter is a better solution, 
in that it avoids potential wasted effort. Nevertheless, to be feasible, any solution should 
be able to recognise correct histories as well as valid prefixes of correct histories. The 
difficulty arises because specifications can vary over time as members are added or 
removed from a TG, and more generally because correctness rests on definitions of cor- 
rect histories and is not easy to prove. 

6.2.8.5 Layered Transaction Model 

Layered transactions were introduced to handle applications that are naturally organised 
in layers like federated databases (four database layers that collect data into a federation 
of local databases, each organised in clusters of objects), operating system transactions 
(ISO/OSI seven layers), and federated DBMSs. For instance, the latter is a collection of 
DBMSs that cooperate loosely but are not fully integrated. It therefore involves the 
coexistence of global transactions, divided into local sub-transactions on the different 
DBMSs, and local (independently issued) transactions active on the local sites. In such 
an architecture, global transactions and local sub-transactions may have a non-serialis- 
able schedule, while the coexistence with local independent transactions causes pseudo- 
conflicts, i.e., conflicts at the database level. 

The layered transaction model is a variant of nested transactions where the nodes of 
the transaction tree define execution of operations at particular levels of abstraction in 
a layered system. L; operations are treated as sub-transactions, and Lj.j operations as the 
actions that constitute sub-transactions. The key idea of layered concurrency control is 
to exploit the semantics of operations in level-specific conflict relations that reflect the 
commutativity of operations. In this way, a schedule at level Lj may be serialisable and 
operations may be executed in parallel whereas their implementation at level Lj.j is not, 
therefore needing a different concurrency control mechanism. Intra- transaction paral- 
lelism is achieved by handling sub-transactions at a lower level uniformly, regardless 
of whether they belong to different ancestors or to the same. In this respect, layered 
transactions are a specialisation of open nested transactions, where the tree of sub-trans- 
actions is balanced. In fact, (1) sibling transactions are executed independently from the 
parents, and (2) each top-level transaction is described at a fixed number of abstraction 
levels, equal to the number of layers of which the system is composed. 

6.2.5.6 S-transaction Model 

S -transactions (where “S” stands for semantic) have been developed for large-scale 
inter-organisational autonomous environments like international banking, to model 
communication protocols. 
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The main basic concept is autonomy; the ability to decide or choose a behaviour dif- 
ferent from what is expected by the rest of the environment. There are various types of 
autonomy. For instance, design (or data definition) autonomy is when an organisation 
has full self-determination with respect to control the structure-type of interactions, i.e., 
when choosing hardware or software, when developing the database schema or other 
applications. S -transactions’ applicability is immediately identified in the fields of 
banking, software engineering, and CIM. 

Transaction structure 

S-transactions are normal transactions associated with a corresponding compensating 
transaction. They preserve isolation and are defined in terms of local data (requested 
either to a remote S-transaction, or to the common database), and entry points (like 
attach channels) for continuations (e.g., sub-transaction activation or remote transac- 
tions' messages) and compensations, thus representing compensating transaction like an 
integral part. 

Transaction primitives 

Both semantic and compensating S-transactions are associated with traditional prim- 
itives Begin, Commit, and Abort. The difference lies in the semantics assigned to them. 
For instance, rules for compensation are defined to enact a compensating S-transactions 
that reverses the effects of the corresponding S-transaction, when the latter has failed. 

Transaction protocol 

The S-transaction model’s potential is fully exploited by applications that manage 
large amounts of complex data, where interacting processes have semantics known in 
advance. Interaction takes place partly on the communication level (message 
exchange), and partly on the inter-operation level (partially ordered sequences of 
actions). 



6.2.9 Summary and Analysis 

The main characteristics of the models presented in Section 6.2.8, are sketched out in 
Table 6.4. It outlines the properties that each model directly addresses and aims to sup- 
port. The objective is to guide the reader in choosing the right model for his/her pur- 
poses. Typical applications are also given For each model, possible answers to property 
coverage are; 

yes, means fully supported, 

yes;<comment>, means that the property is supported, limited to the context indicated 
in the comment, 

no;<comment>, means that the property is not supported, except for the context indi- 
cated in the comment, 

no, indicates that the property is not supported, neither in extended models based on the 
referred one. 
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No indication (i.e., an empty box) indicates that the “pure” model does not address the 
property, even though extended models based on it might do. For each model, the 
answer written in bold indicates the most significant property issued by the model.. 



Table 6.4 Properties covered by advanced models 



Models 


con- 

currency 

control 


co- 

operation 


open- 

ending 


user- 

defined 

correctness 


applications 


nested- 

trans. 


yes 


yes: 

intra-trans. 


no 




CAD/CAM, 

SEE 


split-trans. 


yes 


yes 


yes 




CAD/CAM, 

SEE 


coopera- 
tive trans. 


yes 


yes 


yes 


yes 


design, SEE, 
CSCW, CE 


layered 

trans. 


yes 


no 


no 


no: 

level-based trans- 
actions. commu- 
tativity 


operating 

systems, 

FDBMSs, 

OODBMSs 


S -trans. 


yes 


no 


yes 


yes 


SEE, int. 
banking, CIM 



6.2.9. 1 Available Issues and SEE Transactions 

Transaction support in SEE’s has to fulfil basic requirements that reflect the behaviour 
of software activities. In software development, cooperation and user independence are 
key requirements. The first concerns the possibility of having control in a cooperative 
work environment. The second concerns the freedom to take decisions on-the-fly during 
development, in spite of control (and being therefore responsible for consequences). 
SEE's need therefore to embrace long-lived and cooperative transactions, to adequately 
control software processes. 

Table 6.4 emphasises that concurrency control is managed by all models (at least as 
a contingent topic). Cooperation support, which is one of the most important topics in 
SEE transactions, has been undertaken by all of the described models, except S- and 
layered- transactions, which are specific to user-defined correctness. The last two prop- 
erties are specific to advanced applications and have therefore only been addressed by 
recent models. Nested transactions do not support either of them. Layered transactions 
focus on user-defined correctness. The others support open-ending, which is the main 
topic of split transactions. 

The most advanced support available in commercial systems is through nesting. Fur- 
ther, each system approaches cooperation from various viewpoints. For example, by 
allowing transactions to dynamically start, or by supporting undefined levels of nesting. 
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with an undefined number of sibling sub-transactions, or by transaction sharing among 
multiple-users. 

In general, the nested transaction model suits SEE needs, as; 

a) transaction hierarchy reflects a natural breakdown of work, 

b) transaction nesting implements internal concurrency by allowing sub-transactions 
of the same parent transaction to run concurrently, 

c) recovery is kept under control, by limiting undo to sub-transactions, 

d) dynamic restructuring supports eventual open-ended activities, by allowing transac- 
tion adding and removal whenever a new transaction clustering is needed. 

With regard to user independence, characteristics such as user-defined correctness 
and open-ending are not yet implemented in commercial systems. The main reason 
seems to be the need for a deeper knowledge of the exact definition of correctness in 
SEEs. In fact, being software activities controlled by humans, and due to the differ- 
ences between processes, it is very difficult to define a standard and satisfiable set of 
common statements for consistency. A trend is to allow user-defined protocols to be 
written through rules (e.g., ECA rules), each associated with a transaction class. The 
extension of nesting with the cooperative transaction models seems to be suitable, 
although no commercial or academic results have reached a status stable enough for 
commercial implementation. 



6.3 Impact of Cooperation Control on the Architecture of PSEE 

This section provides more details to the architecture introduced in the previous chap- 
ter from the point of view of cooperation support. It makes no important presumptions 
nor restrictions on the architectural alternatives introduced in (Section 5.2.5, Chapter 
5). Typically, the ADELE system (Section 6.4.3) has an architecture of type II, Merlin 
Section 6.4.2 of type III, COO (Section 6.4.1) also of type III but with some restric- 
tions on the relationships between Process Engines. As depicted in Figure 6.3, we have 
identified five layers of abstraction which can be seen as service layers. 

We will explain the impact of cooperation control on each of these layers. 

The bottom layer is the repository layer. It mainly provides for object and schema 
management services and tool execution services. As emphasised earlier, in a modern 
PSEE numerous resources and software artifacts are managed. The modelling and 
management of these artifacts and their versions needs a powerful object manager. The 
properties of the underlying object model deeply influences the transaction models. 
Clearly, implementing the same transaction model on top of a different data model can 
be of different complexity: explicit links, composite objects, etc. are not easy to man- 
age (to copy, to lock, etc.). On the other hand, distribution of the repository (clearly as 
in architecture alternative IV) generally increases the complexity of synchronisation, 
especially in the case of heterogeneous object management systems and even more so 
in the case of heterogeneous object model. 
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Figure 6.3 Transaction abstraction layers 

In any multi-user environment, processes operate on a limited part of the object base. 
Typically, traditional transactions operate on object copies until commit; that is, copies 
define their working area. We therefore introduce the working area layer to reason 
about process isolation and object transfers without consistency considerations due to 
concurrent object accesses. Thus, the objective of this layer is limited to basic object 
transfers, i.e object identification. However, the characteristics of working areas can 
limit the supported transaction models. Typically, long duration and uncertainty of soft- 
ware processes imply that a working area must be able to outlive the sessions which cre- 
ate or modify it. In addition, the working area layer must be general enough to allow 
implementation of different transaction protocols simply by specializing and/or restrict- 
ing transfers between working areas. 
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The Predefined Strategies for Transaction) layer introduces consistency support and 
provides mechanisms to assert correctness of parallel processes. These mechanisms 
implements synchronisation strategies which are general enough to apply to different 
processes and to he predefined in a PSEE. This indicates that these mechanisms are 
mainly independent of the semantics of the processes which are controlled. Clearly, 
most traditional transaction models come into this category. For example, the 2PL pro- 
tocol [Gray78] only exploits general properties of read and write operations. 

The knowledge layer provides the means to enforce constraints which define software 
development policies. This layer may utilise (or not) the previous layer. Some 
approaches only provide syntactic constructs to model synchronisation, without reusing 
predefined strategies: synchronisation strategies must always he modelled from scratch. 
On the other hand, predefined strategies rest on some consistency hypothesis, and the 
knowledge layer must assume this hypothesis. For example, the 2PL protocol assumes 
that each transaction is an individual correct program: if it executes in isolation and 
starts its execution in a consistent state, then it terminates in a consistent state. In addi- 
tion, knowledge is often used to break traditional isolation of transaction executions and 
to control dynamic interactions 

Finally, the human interface layer assumes the interface between the process and 
human agents. It must allow human agents to create, control and terminate processes. It 
should also allow human agents to be aware of past, ongoing and future work. Transac- 
tion states represent valuable information for a human agent who observes and analyses 
a process. Finally, synchronisation specification can directly influence the process 
design process which is an important part of the interface layer. 



6.3.1 Impact of the Repository on Consistency Maintenance 

Among repository functionalities discussed in (Section 5.1.5, Chapter 5), we stress the 
following as crucial to support consistency maintenance. 

6.3. 1.1 Data Model 

Maintaining consistency means enforcing constraints on object values and process 
states. The richer the data model, the richer the semantics which can be expressed by 
constraints. A consistency-maintenance mechanism based on an Entity-Relationship 
class model is naturally more powerful than a mechanism built on top of a file system. 
We particularly emphasise the use of process knowledge to relax serialisability of tra- 
ditional transaction models as required by software processes. 

New concepts introduced to enhance the modelling power of data models influence 
the complexity of transaction protocols. Conceptually, these new concepts reduce this 
complexity by filling the gap between the real word and its computer description. Tech- 
nically, they increase it due to the need of complex techniques to manage complex 
objects (versioning, locking, copying, etc.). In addition, these techniques are not so 
mature. 
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An analysis of some of the most representative transaction models for PSEE, as 
described below in Section 6.4, indicates the importance of version management in 
transactions. It is not sufficient to distinguish between only two levels of consistency 
(consistent and inconsistent) as is traditional. It is necessary to distinguish between sev- 
eral levels of consistency. That is, at a given time, a logical object can exist in several 
different versions and these different versions must be maintained mutually consistent. 

Another consistency-maintenance capability is the ability to provide different views 
of the object base to facilitate integration of the different points of view which different 
people can have of the process. The more integrated the process description, the easier 
this is to maintain. 

6.3. 1.2 Impedance Mismatch between Object Management 

and Operating Systems 

The less the impedance mismatch between the operating system command language 
and the object management language, the easier it is to maintain consistency of software 
artifacts. 

If tools do not operate directly on the internal process objects which represent the 
state of the current process, but on “converted” files, or through another additional inter- 
face, there is a risk of introducing inconsistencies. 

In addition, we show below how the ability to store system concepts as persistent 
objects provides support for evolution and recovery and other interesting aspects, 
including the ability to model and integrate different synchronisation strategies^. 

6.3. 1.3 ACID Transactions 

There is always a level of abstraction at which a process is a serial execution of ACID 
short-term transactions. As a consequence, the repository must provide ACID transac- 
tions. 



6.3.2 Workspaces: an Abstract Level to Support Flexibility 
6.3.2. 1 A Working Area as a Sphere of Isolation 

A working area manager is intended to identify and to provide software developers with 
(only the) artifacts needed to reach their objectives. This helps avoid unintended, and 
unauthorised manipulation of objects, i.e, to preserve object integrity. 

In traditional transaction models, a working area is seen as a sphere of isolation where 
a software developer can work individually. That is, when a transaction executes, it 
modifies copies of the objects which effectively persist in the object base. These copies 
define the working area of the transaction. 



3. Synchronisation strategy is used as an alternative to transaction protocol. 
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However, strict isolation is not viable for software processes which are interactive by 
nature. Indeed, developers must both be able to work in isolation when they want, and 
to share objects and to synchronise changes on shared objects in different working 
areas, when they want. This idea is central to most transaction models for advanced 
applications. 

This indicates that a working area basically supports the idea of transaction. That is, 
the working area manager provides capabilities to transfer object copies to a place 
where developers can work in isolation. This basic capability is extended to allow shar- 
ing of object modifications. This is specified by the definition of transfer operations 
between working areas, or rather by constraints on these transfer operations. 

6.3.2.1 Reasoning on Transactions as Constraints on Transfer Operations 

Relationships between transaction protocols and constraints on object transfers can be 
easily established. For example, the 2PL can be seen as the following transfer rules; 

a) to operate on an object, a transaction must transfer it from the object base to its work- 
ing area {check out), 

b) an object which is shared between two working areas cannot be modified, 

c) a transaction cannot transfer an object which has been modified from its working area 
to the object base {check in) before it commits, 

d) a transaction which has read an object and frees this object for other transactions can- 
not check out another object. 

Clearly, these rules imply completely isolated execution. Deleting rule c) is sufficient 
to break isolation. It is also sufficient to break all the guarantees of correct execution (of 
serialisability, i.e. correctness must be assumed in some other way). This shows that 
reasoning on consistency maintenance has much to do with reasoning on transfer oper- 
ations between working areas, and vice-versa. 

Returning to our example, this means that to make an object visible before its com- 
pletion, a transaction must use other considerations to assert correctness of executions. 
Section 6.4 shows how more cooperative correctness criteria can be implemented in 
this way. 

Another result demonstrated in [Unla92] is that, if an environment allows definition 
of a transaction protocol by integrating different (sub-)protocols, it is necessary to trans- 
fer i.e. to make a physical copy of an object which is checked-out, both for read and 
write accesses. Thus the working area manager must provide basic transfer operations 
which must not impose limits to transaction protocols, especially if we want to be able 
to allow different synchronisation strategies to run in different working areas. 

6.3.2.3 Relationships between Working Areas 

Relationships between process engines can be specialised to build a specific architec- 
ture: flat, hierarchical, multi-level, etc. Working areas can be similarly structured. 

Typically, a process is often hierarchically organised. A process hierarchy reflects 
rich semantics about cooperation possibilities. Hierarchical organisation also fits the 
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idea of nested transaction. Thus, transfer operations are mostly related to parent-chil- 
dren relationships. 

6.3.2.4 Persistent Working Areas 

Workspaces will normally persist, i.e. working areas exist as objects of the object base. 
This can be used to maintain and express the relationships between working areas, 
transactions and processes. It can supply humans with query possibilities like: 

a) which working areas contain a version of object o? 

b) which is the version of the object o on which the process p operates? 

c) which processes can access version v of object o? 

Note that a persistent working area is close to a sub-object base and inherits some of 
the same qualities in case of failure, i.e the ability to recover a consistent state from a 
previous check point. 



6.3.3 Predefined Synchronisation Strategies Layer 

6.3.3. 1 Classical ACID Transactions 

The first assumption is that some synchronisation strategies can be defined independ- 
ently of a particular software process. The second is that these strategies are sufficiently 
well defined and well accepted to be predefined. It is the fundamental idea of traditional 
database transaction model; it is the case of the classical pessimistic or optimistic trans- 
action protocols. 

As mentioned, traditional transaction protocols are too restrictive for software proc- 
esses, due to the trivial operations they are supposed to support. Fortunately, predefined 
strategies do not imply a traditional strict correctness criteria such as serialisability and 
a rigid protocol such as ACID-transactions. These strategies must rather consider 
aspects of software processes such as user interaction, cooperation, long duration, 
uncertainty and so on. For example, in the COO system, a predefined protocol allowing 
intermediate result visibility has been defined. In Merlin, object consistency is main- 
tained by synchronizing data accesses with four predefined classes of conflicts. Thus, 
the concurrency control protocol can allow interactive execution of processes. 

6.3.3.2 Considering the Human Agents’ Knowledge of the Process 

In both COO and Merlin, resolving a conflict can ultimately rely on the human agent. 
In other words, the predefined strategies, whose goal is to synchronise processes with- 
out taking explicit account of process knowledge, exploit the knowledge of the human 
agents. This can be generalised: the transaction layer must also support the interaction 
between the environment and the human agents in a consistent way, at the appropriate 
place and time. This is especially interesting if we assume that a software process can- 
not be completely modelled in advance. 
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6.3.3.3 Programmable Concurrency Control 

Such concurrency control implies that conflict resolution should consider not only 
(read/write) and (write/write) patterns. It should also exploit pre-programmed patterns 
of the processes involved. 

6.3.3.4 Heterogeneous Protocols 

Different agents in different working areas should be allowed to choose their own syn- 
chronisation strategy, their own concurrency protocol. However, these different indi- 
vidual strategies must be integrated into one global synchronisation strategy, a so-called 
heterogeneous protocol. This implies certain technical consequences, e.g. to copy an 
object each time it is reserved, independently of the mode with which it will be operated 
upon. There are also theoretical constraints on combinations of strategies, A PSEE 
transaction layer must provide not only predefined synchronisation strategies, but 
should also provide predefined means to combine them. 

6.3.3.5 Persistent Transactions 

We emphasise again that persistent transaction structures can facilitate reasoning about 
transactions, especially in the context of programmable concurrency control, of hetero- 
geneous protocols, and to assist error recovery. 



6.3.4 The Knowledge Management Layer 

Knowledge management is crucial for consistency maintenance, whether the PSEE pro- 
vides a transaction layer or not. 

Note that predefined strategies to control concurrency were initially introduced for 
traditional database applications. For software engineering, synchronisation was gener- 
ally explicitly programmed, from scratch. 

The rationale behind each approach is very different. In the former domain, it is not 
possible to forecast all the kinds of interactions between processes; in the latter it is pos- 
sible to completely specify processes and process interactions. In the former domain, 
we must define general, but restrictive synchronisation strategies. In the second domain, 
we must develop specific, but possibly more efficient strategies. 

Both approaches exist in software engineering research, with current SEEs favouring 
either one approach or the other. Nevertheless, the trend is for a mixture of both 
approaches. It is not realistic to assume that everything can be forecast; it is also unac- 
ceptable not to exploit stated knowledge to relax the rigidity of predefined protocols. 

6.3.4.1 From-scratch Synchronisation Strategies 

Some systems do not provide a transaction layer but simply provide syntactic constructs 
to model synchronisation strategies. 
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The SPADE system provides a high level Petri Net formalism to model non tradi- 
tional database applications, including complex dependencies among transactions. 
However, the synchronisation algorithm has to he specified from scratch. 

The ADELE system fits very well with our architecture hut with the transaction layer 
missing. Synchronisation strategies are programmable with powerful triggers which 
specify object sharing rules between working areas. 

6.3.4.2 Predefined Synchronisation Strategy 

As expressed above, any transaction model exploits knowledge of the process, even the 
basic 2PL assumes that serial executions are correct executions, i.e. that individual iso- 
lated processes respect constraints. 

The same assumption applies for advanced transactions models. 

In COO, it is assumed that pre-and postconditions of transfer operations respect some 
rules with regards to safety and liveness constraints. If not, execution correctness cannot 
be proved. More explicitly, it is possible to make visible an intermediate level only if 
the previously applied operations can be compensated in some way. Process knowledge 
is also used by human agents when they are asked to decide how to resolve a conflict. 
Process knowledge is also used in Merlin where a conflict resolution can depend on the 
processes which produced the conflict. 

More generally, process knowledge is a key component in recovering a consistent 
state in case of failure or of reorganisation, i.e. to compensate a process instead of abort- 
ing it. 

6.3.5 The Interface Layer 

The interaction between human interface and consistency maintenance can be seen 
from four points of view: 

a) the software developer who executes processes 

b) the software developer or project manager who observes a process, 

c) the software developer or project manager who makes some prediction on the next 
steps of a process, 

d) the process designer. 

When executing a process, software developers are directly influenced by the con- 
flicts which occur. In case of automatic synchronisation, the interface must at least 
report on conflicts and their consequences. In the case of interactive conflict solving, 
the developer contributes directly to synchronisation, deciding on whether or not to 
allow shared writing, or simultaneous reading and writing of an object. 

When a developer observes a process, the transaction structures contain information 
on the current and past operations which have been applied to objects, and by which 
processes. For instance, we may request which other developer concurrently accesses a 
given object. 
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Prediction of process future and consistency maintenance are related. In most cases, 
both transactions protocols and planning mechanisms exploit the same process knowl- 
edge, i.e. integrity (safety and liveness) constraints. Transaction structures can also be 
directly exploited for this purpose. As an example, inter-dependencies among pre- 
declared transaction intentions are directly exploited to support planning and impact 
analysis. 

Finally, (sub)-process synchronisation must be considered by the process design 
process; different synchronisation rules can lead to different process styles. In COO, for 
instance, processes may execute in a serialisable way or in a cooperative way. A first 
set of design rules produces process models which allow only serialisable executions. 
A second set of design rules produces process models which allow cooperative execu- 
tions. 



6.4 Current Work 



6.4.1 The COO System 

The COO system is a research prototype being developed by the ECOO team at CRIN. 
Its current version executes in a PCTE context. A new version is being designed to sup- 
port cooperation in a Java - Internet Environment with the objective of addressing a 
larger set of applications. The COO project is a continuation of the ALE project to fur- 
ther research the problems related to cooperation support and especially maintaining 
consistency between software artifacts. 

6.4.1. 1 Organisation of Processes 

A COO process breaks down into sub-processes. Each (sub)process executes in its own 
working area governed by its knowledge. Each developer operates through their own 
interface upon objects in their working area: a sub-database which consists of the coop- 
erative versions of the objects in the common repository. 

6.4.1.2 The Repository Layer 

The COO repository, called P-RooT^, implements an object oriented version of the 
PCTE^ interfaces. Its data model is based on an ERA [Chen76] data model extended 
with inheritance, and different categories of relationships between objects (composi- 
tion, reference, designation, existence). The PCTE data types are defined in schemas 
which are used to define the view a process has of the object base. In fact, each process 
is associated with a list of schemas, called its working schema. The view of the process 
on the object base is constrained by the union^ of the type definitions of each schema 



4. P-RooT stands for PCTE Redesign with Object Orientation Technology 

5. Portable Common Tool Environment 

6. Union of two schemas means, for each object type, the union of its properties. Problems due 
to synonyms and homonyms are directly resolved by the typing system 
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in its working schema. Processes are instantiated in the object base as objects. Thus, 
PCTE provides an integration of both operating system services and database system 
services. PCTE provides a closed nested transaction mechanism based on a locking 
mechanism. The P-RooT trigger mechanism is based on a simple event-action mode 
where an event is an operation call and an action is an operation invocation. 
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Figure 6.4 COO Architecture 



6.4.1.3 The Working Areas Layer 

The working area layer implements an object base/sub-base architecture. It provides 
object identification services and version management services. The working area layer 
organises the object base into a hierarchy of working areas. Thus, each working area has 
a parent working area except the initial one which is the root of the working area hier- 
archy and which directly feeds into the repository object base. 
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To operate on an object, a process must transfer it from its chain of ancestor working 
areas to its own working area: this transfer is done by the check out operation. This oper- 
ation creates a new version of the object which is inserted in the working area. Thus, 
several physical copies of the same reference object can exist in different working areas. 
The physical copies of the reference object, we call a reference object a variant, are 
related together through a version graph, i.e. successor/predecessor links. Versioning is 
transparent to processes and a process issues a request to a variant object. To identify 
the version the process must operate on, a mapping is built which associates a physical 
copy of the variant object with the working area from which the request is issued. One 
can transfer a copy of a variant object in the working area into its parent working area: 
this is done by the check in operation. After a check in operation, the transferred copy 
of the variant replaces the previous value of this variant in the parent working area. The 
update operation is used to (re) synchronise an object in a working area with the current 
version of this object in its parent working area. This creates a new version in the work- 
ing area of the process which initiated the request. This new version has two predeces- 
sors: the (old) version in its working area and the version in its parent working area and 
is built by merging the two ancestor versions. The merge operation is done in the current 
working area. Due to the variety of merging operations, we do not provide a general 
merging operation; nevertheless, we will discuss a special case of merging in the next 
section. 

Workspaces persist as PCTE objects. This is of interest in the case of a logical or 
physical failure. It means also that a working area can be considered as a sub-database. 

6.4.1.4 The Predefined Strategies Layer 

In COO, we distinguish between three levels of consistency: 

a) globally stable objects. 

b) locally stable objects. 

c) intermediate result objects. 

Globally stable objects are objects which are consistent with regards to any process 
definitions. Locally stable objects are objects which are consistent with regards to the 
local process definition, but which can be inconsistent with regard to one or several 
enclosing processes. Intermediate results objects are objects which can be inconsistent 
with regard to the definitions of the process which produced them, and which can be 
operated on again by this process. 

Processes are hierarchically organised and when a process wants to access an object, 
the version of the object it will attempt to obtain is: the closest intermediate result of this 
object if it exists, or the closest locally stable object if it exists and no intermediate result 
exists, or finally the globally stable object. 

Clearly, visibility of intermediate results allows the relaxation of the constraint on 
isolated execution by allowing a process to see intermediate results of siblings. Inter- 
mediate results are transferred by a transfer activity called upward commit. To maintain 
consistency with intermediate results, we say that, when a process A has read an inter- 
mediate result of a process B, A depends on B. When a process depends on another proc- 




144 6 Cooperation Control in PSEE 

ess, it cannot terminate without updating the intermediate result in the dependence with 
the corresponding final value. The refresh operation is a special case of update where 
the merge operation consists simply in the replacing of the value in the child working 
area hy the value in the parent working area. By nature, commit dependencies can be 
crossed, and more generally, the dependency graph can be cyclic. In such a case, all 
processes in a cycle are requested to terminate “simultaneously” with the same values 
of objects involved in the dependencies. This is implemented by a kind of two phase 
commit protocol inspired by [Gray78]. Check in is now reserved for the transfer of final 
results (marked as final). It means the objects cannot be modified again by the same 
process. We authorise (advanced) check in of an object. 

A COO process executes as a nested transaction. The root transaction represents the 
whole process, at the leaves are atomic processes called activities, at the intermediate 
levels are compound processes called tasks. A task is simply a synchronisation entity: 
it delegates object modifications to its enclosed activities. Each time a process is initi- 
ated, structures are created, including a new working area and a check out is done on all 
input (parameter) objects. A transaction completes when the enclosed process succeeds 
in executing its terminate activity. The effect is to check in any results which have not 
already been checked in. 

An intermediate result can be produced only if the process which produces it is com- 
pensatable. In other words, transfer operations must be constrained, and, in the worse 
case, intermediate results must be prohibited. To support this unfavourable case, the 
default protocol implemented in COO is the 2PL nested protocol, where check out and 
check in encapsulate respectively the role of read and write. Atomicity of basic activ- 
ities is assumed by the repository level: all activities, including transfer activities, exe- 
cute in isolation. Then from this basis, to support interactions, the 2PL compatibility 
table can be modified to allow, on the authority of human agents, a transaction to 
upward commit an intermediate result, i.e. a transaction to read an intermediate result 
of another transaction and two transactions to write the same object. This decision rests 
on the responsibility of the human agent or can be programmed depending on the proc- 
esses in the conflict. 

Finally, note that all transaction structures persist. This is of the greatest importance: 
in recovering a consistent state in the case of a logical or physical failure, in defining 
new predefined synchronisation strategies, and in integrating different strategies in the 
same protocol. 

6.4.1.5 The Knowledge Layer 

The transaction layer assumes consistency on the basis that processes are consistent 
with respect to their definitions. As the COO PML is logic based, activities, including 
transfer activities (check in, check out and upward commit), are extended with pre- and 
post-conditions. 
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6.4.1.6 The Interface Layer 

COO provides a means to assist process design. We distinguish between a conceptual 
level where software development rules are expressed in a limited form of temporal 
logic and a logical level where these rules are implemented in terms of pre- and post- 
conditions on activities. 

The behaviour of a process is defined by aggregating several schemas which define 
its context. It means at least the P-RooT schema, the Workspace schema, one Transac- 
tion schema, and one Constraint schema. This provides a very flexible and extensible 
way to model and enact processes. As an example, for a given process model, choosing 
between a serialisable and a cooperative execution mode is simply a matter of choosing 
between one constraint schema and another. 

6.4.1.7 The Cooperation Example 



As a short illustration, let us consider how COO manages the situation depicted in our 
motivating example in Section 6.1.2, Scenario 2. 

Table 6.5 A correct scenario 
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Table 6.5 A correct scenario 





refresb(interface(A) ) 


POCM(B) refreshes its current 
value with this new value 


edit_body(A) 

compile_body(A) 

terminate(POCM(A))* 


edit_body(B) 


POCM(A) declares all its results 
as final results, including the inter- 
face of A 




compile_body(A) 
terminate(POCM(B )) * 


as it has read the final valne of the 
interface of A, POCM(B) can com- 
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* init and terminate are COO activities introduced to manage pre- and post-conditions 
of compound processes. Especially, when a process terminates, it checks_in all its 
results which are outstanding. As a consequence, it declares them as final results. 

Circulation of the interface of A between workspaces in the related scenario 

Figure 6.5 shows the circulation of the interface of A between POCM(A) and 
POCM(B). This is controlled by Coding Task. In particular. Coding Task will not 
accept POCM(B) to terminate if it has not read the final value of the interface of A. 



Process Modelling 

A process model (PM) in COO is a 7-tuple < S, V, H, P, O, I, C> where 

a) S is the Signature (parameter types) of the PM, 

b) V is the View of the PM on the object base, 

c) H is the Human Agents (roles) needed to enact a process of the PM, 

d) P is the Precondition of the PM, 

e) O is the Objective of the PM, 

f) I is the Implementation of the PM, i.e. the list of sub-process models, 

g) C a set of integration constraints which describes how sub-processes can interact to 
reach the goal of a process they implement (we distinguish between safety and live- 
ness constraints). For more about this model, see [Goda93a, Goda95]. 

The process Coding Task which governs our example scenario is primarily related to 
the liveness constraint which says “if the interface of A is modified and B is a module 
which depends on A, the body of B must be modified before Coding Task terminates”. 

In our PML, it is translated; 

from new((interface(A)) and depends_on(A,B)) sometime new(body(B)) before ter- 
minated 
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CODING TASK 




- — — — Repetitive upward_commit of an intermediate result (points 1,3,4) 
and finally check in (point 6) 

First check out of an intermediate value of this result (point 2) 

Refreshing of this intermediate result(, at least) with the final 
value (point 5) 

Figure 6.5 Circulation of the interface of A. 

To maintain this constraint, we introduce the predicate: inevitable_before (I_B(A;,B)) 
which allows the storage of the useful history. If this predicate exists, it means that a 
value of the interface of A (Aj) needs to be consumed to update the value of the body 
of B (B|^) before Coding Task is able to terminate. 



We can transform this constraint into preconditions and postconditions of the activi- 
ties as shown in the following table. This table results from the application of our trans- 
formation rules as described in [Goda95]. 



Activities in 
POCM(A) 


Activities in 
POCM(B) 


Preconditions 


Postconditions 








insert^(I_B(Aj,B)) with B 

depends on Aj 


:heckin(Aj) 






insert(I_B(Ai,B)) with 

B depends on Ai 








ielete(I_B(Ai,B)) 




terminate 


there is no I_B(Aj,B) 





a. “insert a tuple” effectively inserts this tuple only if it does not already exist. 
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6.4.2 The MERLIN System 

The MERLIN system has been developed by the Software Engineering team at Pader- 
born with a particular interest in the impact of cooperation on consistency maintenance 
and user interfaces. 



Interface 


process view management 

process design assistance (OMT->Prolog) 




Knowledge 


logic based process modelling 
Prolog rules 




Predefined Strategies 


cooperation patterns 

synchronisation rules for process transaction 




Working areas 


O 2 views 




Repositories 


O 2 



Figure 6.6 MERLIN Architecture 
6.4.2. 1 The Working areas Layer 

In contrast with many other PSEEs the Merlin Session Layer is not implemented as a 
base/subbase implementation with check out and check in functionality. All documents 
of a particular configuration reside in a common repository. For each user the Work- 
space Management (cf. Section 5.1.4, Chapter 5) creates his/her personal workspace as 
a view on all documents depending on the users identity, role and access rights. In this 
approach intermediate modifications are immediately propagated to all other users with 
changed documents in their workspace. 

Transactions are initiated by a user corresponding to his/her personal workspace, e.g. 
the user may start a working context transaction (wcCP)^ to control all activities per- 
formed on documents in this workspace. In the case of conflicting transactions, such 
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that an activity (e.g. editing a document) has to be aborted, the user can store his/her 
intermediate results as a new document version that may be merged with the current 
version after the other conflicting transaction has committed. 

6A.2.2 Cooperation Patterns 

Cooperation Patterns (CP) have been developed in Merlin to coordinate multiple users’ 
work. They correspond to transaction types. In “traditional” applications only one type 
of transaction exists, namely the ACID-like transactions mentioned in Section 6.2.1 
Merlin distinguishes CPs used to control user performed activities and CPs used to con- 
trol activities which are performed automatically by the PSEE. 

The CPs used to control user performed activities differ with respect to the number of 
objects they access. A CP either controls the execution of a single activity on a single 
document (e.g. editing a module) or it includes and controls all activities performed 
within a working context (e.g. editing several source code modules, compiling and link- 
ing them). The first one is called activity CP (aCP) and the second one working context 
CP (wcCP). 

Merlin further distinguishes two CPs to control automatically executed activities. 
Either the PSEE follows some automation conditions in the process definition, and 
therefore changes the states of documents and invokes tools (e.g. compilation of a mod- 
ule after the imported modules have been finished), or document accesses and corre- 
sponding document state changes are triggered by some consistency conditions (e.g. re- 
compilation of an already compiled module because an imported module has been mod- 
ified). The CPs corresponding to the latter two types of activities are called automation 
CP iautoCP) and consistency CP (consCP) respectively (this distinction is similar to the 
separation between automation chains and consistency chains in Marvel [Barg92]). 

Each transaction, or rather activity performed, is considered to be an instance of one 
of the above defined CPs. As those transactions are based on specific knowledge about 
a software process model definition, we call them process transactions in order to dis- 
tinguish them from ACID-like transactions in the traditional sense. A process transac- 
tion is defined as a tuple T = (i, cp, u, r, L, T, p) with 

a) i;the transaction’s Identifier 

b) cp;CP applied for the transaction cp £ {aCp, wcCP, consCP, autoCP} 

c) u; Identifier of the user who initiated the transaction 

d) r; role of the user who initiated the transaction 

e) L; Locks, L c {1^, l^^l Ij is lock} with 1; e (w(D),r(D), w(state(D)), r(state(D)) I D 
is a Document) 

f) T;Timestamps with T c {tj, ..., tj^l t; is timestamp) with t; £ (tw(D,T), tr(D,T), 
tw(state(D),T), tr(state(D),T)l D is a document, T is a point in time) 

g) p; Identifier of the parent transaction 



7. Cf. the earlier definition of process transaction and cooperation patterns. 
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Besides a unique identifier of a process transaction and the CP which defines the syn- 
chronisation of the transaction with others (see below), the user who initiated the trans- 
action as well as the user’s role are associated with the transaction. This information is 
provided to users involved in a concurrency conflict. 

Transactions are synchronised either in a pessimistic or optimistic way. In the pessi- 
mistic case attribute Locks describes the locks held by a transaction. In the optimistic 
case attribute Timestamps describes a set of timestamps. The last attribute parent con- 
tains the parent transaction identifier, if the transaction is initiated as a subtransaction. 

6.4.2.3 Synchronisation Rules for Process Transactions 

The following three sets of rules form the fundamental basis for synchronizing concur- 
rently running process transactions. 

(1) All transactions except those of type aCP are synchronised in a pessimistic way, 
i.e. if a transaction is started all needed locks are acquired. The transaction is not started 
if a lock cannot be acquired. A transaction of type aCP can run in an optimistic or pes- 
simistic mode. In the case of an optimistic mode, its timestamps are validated at the end 
of its execution. If another transaction has acquired locks the optimistic transaction of 
type aCP is aborted. If another optimistic transaction of type aCP has committed 
already and has accessed the same objects while they were accessed by the transaction 
to be validated, the transaction is also aborted. 

(2) Synchronisation is based on the definition of priorities. In case of a conflict the 
access right is usually granted to the transaction that has the highest priority whereas the 
other is aborted (exceptions from this rule exist, as the example below will show). 
Transactions of type consCP have the highest priority because they are applied to pre- 
serve the consistency of a process. Next at the same level of priority are transactions of 
type wcCP or aCP, if the pessimistic mode has been chosen for the latter one. Next are 
transactions of type autoCP. Transactions of type aCP have the lowest priority, if the 
optimistic mode has been chosen. 

(3) Transactions of type consCP or autoCP are always executed as subtransactions of 
transactions of type wcCP or aCP, because activities automatically executed by the 
PSEE are always triggered by a user activity. The subtransactions have access to the 
locks still held by the parent transaction. In case the parent transaction is of type aCP 
in optimistic mode the timestamps are transformed to locks at validation time. If the val- 
idation fails, the parent transaction is aborted. 

These rules avoid the situation where consistency or automation activities triggered 
by a user’s activity cannot be performed because in the meantime locks were acquired 
by other transactions. For example, a compile activity is triggered and performed when 
a user has finished editing a module. Consequently, a project, i.e. all its corresponding 
documents, is always in a consistent state. 

Based on these rules we have defined a number of more sophisticated synchronisation 
rules which we do not give in full detail here but refer to [Junk94]. The following exam- 
ple should illustrate that even withdrawing locks is a possible conflict resolution. 
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Consider the conflict between a transaction of type wcCP or aCP (in optimistic mode) 
on one hand and a transaction of type consCP on the other. In such a conflict, it is dis- 
tinguished whether or not the wcCP- or a CP- transaction has already started subtransac- 
tions. 

The first case means that the user has already finished his activity in the working con- 
text. If a subtransaction (of the wcCP or aCP transaction) of type consCP concurrently 
accesses the parent’s lock which causes the conflict, the requesting consCP is aborted. 
If a subtransaction of type autoCP currently accesses the parent’s locks, the transaction 
of type autoCP is aborted and the lock is withdrawn from the parent transaction of type 
wcCP or aCP. If no subtransaction currently accesses the parent’s lock, the lock is with- 
drawn from the transaction of type wcCP or aCP. 

In the second case (no subtransactions initiated yet, i.e. the user activity is still run- 
ning) it has to be distinguished whether the conflict is caused by concurrent accesses to 
a document or a document state. If the transaction of type consCP requests a state lock, 
this lock is divested from the pessimistic transaction of type wcCP or aCP without 
aborting the transaction. This solution is based on the specific application knowledge 
that a document’s state is only changed by the user at the very end of the development 
activity. Withdrawing the state lock enables the user to continue the activity (e.g. edit- 
ing a source code module), but does not allow him to change the module’s state at the 
end of his activity. In order to change the state, the user has to finish his/her activity and 
to start a new one later. Note, that the performed modifications are not lost. Only if the 
conflict between a consCP-transaction and a wcCP- or a CP- transaction concerns a doc- 
ument’s lock, the transaction of type wcCP or aCP is aborted. Then the already per- 
formed modifications are stored in the user’s private workspace. Thus a new version of 
a document is created. Furthermore the “losing” user is informed about the user who 
caused the conflict (and that user’s role) such that the two users are able to discuss fur- 
ther synchronisation of their work, possibly off-line. 

6.4.2.4 The Knowledge Layer 

The Merlin transaction model and in particular the synchronisation rules are formally 
defined in a set of PROLOG rules. These rules are efficiently executable and act as an 
inference engine for software processes. A particular software process is defined in an 
OMT-like notation [Junk94] which is mapped to PROLOG facts and thus can be inter- 
preted by the inference engine. 

Further PROLOG mles define all the preconditions which have to be fulfilled in order 
to build a particular user’s working context or to execute a particular activity. A partic- 
ular working context or the intended execution of an activity are described as PROLOG 
goals. By interpreting the PROLOG program the PSEE checks preconditions, for exam- 
ple, a user’s responsibilities, access rights or document states. An activity whose pre- 
conditions are true is displayed in a working context (possibly on demand) or 
automatically executed (e.g. compile). Performing an activity could result in new pre- 
conditions becoming true (based on the user input of status information, or on the results 
of automatic activity executions) and consequently new activities displayed. The 
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PSEE’s major job in the context of managing working contexts is thus to evaluate all 
preconditions and to refresh all displayed working contexts accordingly (on demand). 

6.4.2.5 The Repository Layer 

In Merlin the fully object oriented database system, O 2 [Banc92] is used to maintain all 
information about software development projects including access rights on documents 
and document states. The schema is defined using O 2 C which is an object oriented 
extension of the programming language C. Furthermore O 2 provides an implementation 
of the standard DDL/DML for object management systems proposed by ODMG 
[ODMG97]. O 2 provides a simple ACID transaction mechanism for optimistic and pes- 
simistic transactions. The Merlin transaction model uses pessimistic (short time) ACID 
transactions to modify those PROLOG facts that reflect the current state of the coop- 
eration model. 

6.4.2.6 The Example Scenario 

In this section we apply Merlin process transactions to the sample scenario. Table 

6.6 maps each activity of the scenario (middle column) onto the corresponding process 
transaction^ (right column). Nested process transactions are explicitly marked by a shift 
to the right. Each event (starting or terminating process transaction) that results in a 
modification of a document state is given a unique number in the left column. These 
event numbers are used to illustrate the transitions of the four documents in Figure 6.7 
over. 



Tahle 6.6 Application of Process Transactions to the Scenario 



Event 


Activity 


Process Transaction 


1 


edit_interface(A) 


(il, aCP, -, Ti) 


1.1 




O2, autoCP, 
{w(state(body(A))}, i^) 


2 


edit_interface(B) 


(ij, aCP, -, T2) 


2.1 




(i4, autoCP, 
{w(state(body(B))}, i3) 


3 


edit_body(B) 


(ij.flCP, -, T3) 


4 


compile_body(B) 


{i(^,autoCP, 

{w(state(body(B))}, i5) 


5 


edit_body(A) 


(i7, aCP, -, T4) 


6 


compile_body(A) 


(ig, autoCP, 
{w(state(body(A))}, i-j) 



8 . In this notation of process transactions identity and role of users are skipped for sake of better 
readability, since there is no need of these attributes here. 
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Table 6.6 Application of Process Transactions to the Scenario 



Event 


Activity 


Process Transaction 


7 


edit_interface(A) 


(i,, aCP, Tj) 


7.1 




(ijo, consCP, {w(state(inter- 


7.2 




face(A))), i,) 


7.3 




(ijj, consCP, 


7.4 




{ w(state(body(A)), 
w(state(body(B)))), i^) 
edit completed 
(i[ 2 , autoCP, 

[ w(state(body(A)), 
w(state(body(B)))), i^) 


8 


edit_body(A) 


(il 2 , aCP, -, Tg) 


9 


compile_body(A) 


(ij 3 , autoCP, 
{w(state(body(A))}, ii 2 ) 


10 


edit_interface(A) 


(il 4 , aCP, T 7 ) 


10.1 




(ij 5 , consCP, {w(state(inter- 


10.2 




face(A))), i[ 4 ) 


10.3 




(ijg, consCP, 


10.4 




{w(state(body(A)), 
w(state(body(B)))l, ii 4 ) 
edit completed 
(i[ 7 , autoCP, 

{ w(state(body(A)), 
w(state(body(B)))l, ii 4 ) 


11 


edit_body(B) 


(ilg, aCP, -, Tg) 


12 


edit_body(A) 


(ijQ, dCP, Tg) 


13 


compile_body(A) 


(i 2 o, autoCP, 
{w(state(body(A))l, ii 9 ) 


14 


compile_body(B) 


(i 2 i, autoCP, 
{w(state(body(B))l, iig) 



Figure 6.7 is a diagram that shows the sequence of state transitions for each document 
in the example. States are represented by ovals while directed edges denote transitions 
between states. The initial state is as noted at the top of each diagram. Edges are anno- 
tated with event numbers in order to have a mapping with process transactions that 
cause the corresponding transitions (Table 6.6). 



6.4.3 The ADELE System 



The ADELE system is developed at the LSR-IMAG laboratory in Grenoble. It was ini- 
tially designed to manage versions and configurations during software development, 
and there is a commercial version that is confined to this task. In this section we will 
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Interface of Module A 


Body of Module A 


Qiot_yet_specifie^ 


^ could_not_be_imptemented) 


k 7.3, J 0.3 


7.2, 10.2^ \l.l, 7.2, 10.2 


7.1, io.r\^ ^ 


. i . I 

\Compiledj ^ not_yet_implemented'^ 


^ specified 


6 9 / ^ 

(implemented ^ 


Interface of Module B 


Body of Module B 


Qiot_yet specified 


^ could_not_be_implementei() 




7.2, 10.2,^ ^2, 7.4, 10.4 

(compiled^ ^ not_yet implemented ^ 


^ specified ^ 


4,lS^ ^3,11 

(implemented ^ 



Figure 6.7 State Transitions of Evolved Documents 

consider an enhanced version, which the objective of improved support for “Team 
Work”. 

6.4.3. 1 The Repository layer 

ADELE proposes its own data repository as default. The ADEEE data model is 
designed for the support of Software Engineering work in general, and configuration 
management in particular. It features an EER (Extended Entity Relationship) model, 
where relationships are first class citizens, with identity, attributes and methods, in the 
same way as objects. Multiple inheritance is available for both objects and relation- 
ships. Special attention was devoted to complex object control. Composition relation- 
ship semantics is not predefined by the system but explicitly declared by the data 
modeller. Components of complex objects can be automatically found using explicit 
built rules. This is an extension of configuration construction, where components can 
be found using the “dependency” relationship and selection rules. 

ADELE considers the Eile Systems as one of its repositories, and as such, most com- 
mands can work in the same way on files in a file system or on its data repository. 
Recovery and transactions span over all the repositories. 
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Figure 6.8 ADELE Architecture 
6.4.3.2 The Working Areas Layer 

A working area, called Workspace (WS), is a kernel concept. It is built as a part of the 
DB. A WS is the implementation of a sub DataBase: an identified sub set of another 
WS, where the original WS is the repository. Thus WSs are nested, the DB being a tree 
ofWSs. 

The kernel WS manager recognises two classes of WSs, Database WSs and File Sys- 
tem WSs. A Database WS is a sub-DB, i.e. a sub set of the entities and relationships 
pertaining to another WS. The WS manager is responsible for the identification of the 
entities, to ensure transfers between the original WS (the parent), to the destination (the 
child), and to avoid any malicious or unintended access to objects not pertaining to the 
WS. All transfers are implicit and transparent. 

WSs raise the granularity of most commands from a single file to the whole WS, for 
example: create, delete, resynchronise. WSs are created by the make Workspace com- 
mand “mkws ohject-list -t WS_type ...”, which is issued from parent WS, hy default the 
repository (i.e. the root WS). This granularity is much closer to the engineers’ concep- 
tual world. For instance “mkws V2Conf -t develop -u Jim’’ creates for Jim a develop- 
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merit WS containing the configuration VlConf, itself containing perhaps thousands of 
files (in other words, files can be checked-out set by set). 

A File System WS is the file system image of aDB WS i.e. all WS object representing 
a file is really a file in a file System. A File System WS acts as an extended file system, 
with attributes, relationships and abstract objects. A component, the “File System Map- 
per” is in charge to translate any command argument from files into their corresponding 
objects. ADELE Eile System WSs are transparent, i.e. users and tools work as normally 
in a real file system, with no changes in routine and (almost) no overhead. 

6.4.3.3 Predefined Strategies 

Shared or private workspaces 

A WS has a parent (except the root WS), and may be one of several different children. 
Each child contains a sub set of the objects of its parent. Cooperation refers here to the 
way the “same” object is managed in both WSs. The kernel WS manager recognises 
only two cooperation policies: Shared and Private. 

Shared means that the parent and its child really share the same object, i.e. a change 
is immediately visible in both WSs. It exists physically as a single object, with no con- 
currency control except the DB short ACID transactions, and the explicit locks pro- 
vided as part of the Configuration Manager. 

Private, conversely, means a WS acts as a (very long) ACID transaction containing 
persistent objects i.e. changes are local to the WS, and any change performed outside 
the WS are not visible. In long transactions, as soon as an object is modified, the kernel 
WS manager creates, transparently, a copy of that object, visible and accessible only in 
that WS. In short transactions, a lock is set to prevent conflicts. At WS commit changed 
objects are resynchronised (i.e. merged) with their original in the parent WS. Change 
propagation is only allowed along the WS tree, and at WS completion. 

WSs are typed, and a different policy can be set for arbitrary set of objects. Thus a 
part of a WS can be shared, and the rest can be private. Using only the kernel WS man- 
ager, most of the usual cooperation policies can be implemented. 

Rules library 

An advanced feature of ADELE is that it allows tried and tested synchronisation strat- 
egies to be organised in libraries. In other words, a strategy which has been developed 
in a process, and whose correctness has been established through “experimentation” can 
be stored to be reused in another process. Strategies are expressed as Event-Condition- 
Action mles, see Section 6.4. 3. 4 . 

6.4.3.4 The Knowledge Layer 

A strategy formally defines which kind of data must be transferred between WSs, at 
which time, and between which WSs. It extends the kernel WS manager in that (1) 
cooperation can be implemented between any pair of WSs with common objects (not 
only the parent/child tree), (2) the data exchange can take place at any defined instant 
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(not only at WS commit), (3) different policies can be active simultaneously for a given 
object with respect to different coordinated WSs (instead of a single parent coordinated 
WS), and (4) cooperation policies can be set, removed and modified at any time 
between any WS pair. 

The DB becomes a network of coordinated WSs, exchanging information in a prede- 
fined manner, and following an explicit model. 

A WS type is defined explicitly, WS instances are objects themselves. The process 
engine notifies the WS manager each time an event occurs on an object. The WS man- 
ager, if the object is coordinated, and depending on the coordination policy(ies), dis- 
cards the event or executes the action defined in the policy. (The action may be merge 
both objects, notify the user, ask the user what to do etc.). 

A WS type is defined as follows: WStype = (Content*, Sub WSs*, coordinated*, role) 
with 

a) content, the list of object types contained in the WS, 

b) Sub VTS the child WS types, 

c) Coordinated: Coord = {OrigWS, DestWS, which, when, policy}, with OrigWS and 
DestWS the coordinated WS pair; which a filter defining which objects are the sub- 
ject of the policies, when is a condition expressing when the policy must be executed, 
and policy is what is to be done when the when condition becomes true. Examples of 
coordinations are given in C1-C4 below. 

Integration = (SourceCode, {Analysis, Development), (Cl, C2, C3, C4j, Integrator) 
where: 

Cl = (Self, Analysis, SourceCode, True, shared) 

C2 = (Self, Development, SourceCode, True, private) 

C3 = (Development, Development, (!type = Header), save, resynch), 

C4 = (Development, Development, (hype = Body), become_ready, notify); 

Line 1 expresses that Integration WSs contain SourceCode, have sub WSs Analysis 
and development, uses coordination Cl to C4, and are used by engineers with the role 
of Integrator. 

Cl expresses that Analysis WSs are sharing the source code with the Integration WS 
{selj). C3 expresses that between any two Development child WSs, the headers are to 
be resynchronised as soon as a modified Header is saved. 

C4 expresses that a notification (notify) is to be sent to the WS responsible as soon as a 
program body becomes _ready. The event becomes _ready being defined as “event 
becomes_ready = (!cmd = mda and !a = state and !val = ready)” i.e. the state attribute 
is changed to ready. 

Cl and C2 simply use the kernel WS facilities, while C3 and C4 define advanced 
cooperation policies, based on a library of predefined policies. 




158 6 Cooperation Control in PSEE 
6.4.3.S The Interface Layer 

In particular, this layer supports the modelling of software project activities. It is organ- 
ised in two parts. The basic process engine language, based on triggers, and two 
advanced formalisms: the Tempo and APEL process languages for the definition and 
enactment of process models. 

The basic process engine interprets all the events occurring in the system according 
to the current process model. Events are all accesses to the system, or accesses to any 
data (objects as well as relationships) contained in any repository. Pertinent events are 
explicitly declared. Triggers are Event-Condition-Action rules, and are defined as part 
of a type definition. 

The high level languages include constructs to describe: (1) the activities related to a 
life cycle model, (the model specifies the objects to manipulate, tools to invoke, the 
authorised agents, and constraints to check the validity of operations carried out in an 
activity), (2) relationships between the activities, (decomposition of an activity into 
subactivities) (3) the coordination among the activities (sequencing, parallelism, data 
flow) which specifies certain constraints on the execution of activities. 

Tempo is a textual language emphasizing an object oriented style for process descrip- 
tion. One feature of Tempo related to synchronisation is that it offers advanced mecha- 
nisms for cooperation support. We have identified two major capabilities. The first is 
the process layer which defines specific scenarios for cooperation and synchronisation 
appropriate for these scenarios. The software process is specified as long term and com- 
plex events which perform activities in response to appropriate conditions. The second 
is the cooperation layer which controls the degree of parallelism in resource sharing 
allowing different strategies on a per-application basis, without using transactions hier- 
archies. 

In combination with Tempo, APEL (Abstract Process Engine Language) is a graphi- 
cal language primarily designed for capturing and understanding processes. Then, by 
recursive refinement, the degree of description becomes sufficient for generating the 
code for enaction. APEL offers process engineers four aspects: Control flow (including 
multi instance activities, control by event), data flow (including asynchronous data 
transfers), data definition (including versioning and measure aspects), and Work Space 
(including cooperation policies, user role and State Transition aspects). 



6.4.4 The SPADE System 

The SPADE system [Band93, Band94, Band94b] is developed by the Software Engi- 
neering Team at Politechnico di Milano. Software processes in SPADE are specified 
using a high-level Petri net notation which covers all aspects of processes, including 
cooperation. 
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6.4.4.1 SPADE Architecture 

The SPADE architecture is structured in four different layers: the Repository, the Proc- 
ess Engine, the User Interaction Environment, and the SPADE Communication Inter- 
face. The Repository stores both process model fragments and process artifacts. It has 
been implemented on top of the O2 database. The Process Engine is responsible for the 
execution of the SPADE EANGuage (SLANG) process models. Different fragments of 
a process are associated with one SLANG interpreter that executes as a thread of the 
Process Engine. The User Interaction Environment (UIE) is a collection of tools, avail- 
able in the development environment, that take part in the process enactment. Process 
users always interact with the Process Engine through the services provided by these 
tools. The SPADE communication interface (SCI) behaves as a communication bus, 
connecting SLANG interpreters with tools in the UIE. The SCI defines a message based 
control integration protocol. To extend the scope of the process model control to other 
tools that do not know this protocol, a number of bridges can be added to the SCI. A 
bridge is a gateway that translates control messages from the SCI protocol into another 
control integration protocol. SPADE comes with bridges for DEC EUSE, SUN 
ToolTalk and Microsoft OLE/DDE. 

6.4.4.2 SPADE Language 

SPADE defines a process modeling language called SLANG that supports process 
description from two different perspectives. The data perspective is given by a set of 
classes (or abstract data types) called ProcessTypes, and the workflow perspective is 
given as a set of activities called ProcessActivities. The two process views are inte- 
grated: the data manipulated by activities in ProcessActivities are instances of the 
classes contained in ProcessTypes. 

The ProcessTypes set is organised in a class generalisation hierarchy, following an 
object-oriented style. Each class has a unique name, a type representation, and a list of 
operations, that may be applied to objects of the class. Each class can be used to repre- 
sent different kinds of process data in the process model. Process data includes: process 
products and by-products (source code, executable code, design documents, specifica- 
tions, etc.), resources and organisational process aspects (such as roles, skills, human 
resources, computer resources, etc.), as well as process model and state information (for 
example, activity definitions, activity instances, class definitions etc.). 

Each activity in the Process Activities set describes the workflow within a process 
fragment. Activities are specified using a high-level Petri net notation. Petri net transi- 
tions represent process steps and Petri net places behave as typed data (token) contain- 
ers. The Petri net topology of an activity describes precedence relations, conflicts, and 
parallelism among process steps. Usually, a transition affects only the data contained in 
its pre-set and in its post-set and corresponds to a transaction in the underlying database. 
Some special transitions, called black transitions, are able to affect the User Interaction 
Environment by executing tools and invoking the services provided by these tools. An 
activity definition may also include the invocation of other activities. 
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6 . 4.43 The Concurrent Coding Activity Example 

To show how coordination and data sharing are managed in SPADE, let us consider the 
motivating example presented earlier Section 6.1.2 . This process is the parallel coding 
of two modules, A and B. These two modules are interdependent. In particular, B 
depends on A. According to the Scenario 2 (see Table 6.2), the coding of the modules 
can he performed in parallel, provided that the last version of module B is generated 
using the last delivered version of module A. 

Figure 6.9 shows the SLANG activity that describes the process of coding one of 
these modules. The activity is parametric with respect to the module to be developed, 
that is, it describes the process to be followed for coding any of the modules composing 
a software system. When needed, this activity can be instantiated in multiple active cop- 
ies, that are executed in parallel by different SLANG interpreters for supporting the 
(possibly parallel) implementation of several modules. Figure 6.10 shows a process 
fragment in which two instances of this activity are invoked. Places InfoModuleA 
and InfoModuleB contain, at the invocation time, the information related with the 
module to be coded. Place GlobalWS is shared between the two activity instances, that 
is, both activities can use and change its contents. GlobalWS represents a common 
workspace in which the modules under development are stored in their intermediate and 
final versions. As for Figure 6.9, the coding activity is started when the information on 
the module to be coded are available in the input place called InfoModule. Each 
module in InfoModule is characterised by a name, a person responsible for its devel- 
opment, and a list of modules it depends on. 

All the modules under development are represented by tokens in the shared place 
GlobalWS^. Each module in GlobalWS is characterised by a version number that is 
increased each time a new version of the interface of the module is developed^*^. 

The definition of the coding activity supports users in executing the following steps; 

a) edit the interface of the module; 

b) edit the body of the module; 

c) compile the coded module; 

d) terminate the execution of the coding activity. 

Users issue commands related to these steps using some tools in the SPADE UIE. 
These commands are received by the coding activity as tokens in place UserCom- 
mand. This is a special place (it can be distinguished by the others for its graphical 
appearance), called user place, as it is used to manage the interaction between the UIE 
and the Process Engine. A user place can be configured to receive specific types of mes- 



9. GlobalWS has associated a type called module. This type characterises all the tokens that can 
be stored in the place. For the sakeof brevity, type definitions and transition codes are just infor- 
mally described. 

10. For the sake of simplicity, in this context, we do not consider the problem of how to manage 
several versions of the same module. In the example, we just keep track of the number of inter- 
face versions that have been developed for each module. 
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sages. In this example, transition Conf igureUserPlace enables place UserCom- 
mand to receive all the commands of editing, compilation, and termination issued for 
the module whose development is supported by the activity. The occurrence of a token 
in UserCommand enables transitions editinterf ace, editBody, compile, or 
TerminateCoding. They fire provided that their guard is true. 

Let us consider the flow of the process when transition editinterf ace fires. In 
this case, a request to edit the interface of the module is represented by a token in place 
UserCommand and a token representing the module is in place ModuleToCode (this 
happens if no other editing operation on the same module is being performed). The fir- 
ing of editinterf ace starts the editing procedure and enables the execution of 
check -outDepend. This last one makes a local copy of all the module interfaces on 
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which the module to be coded depends. In particular, the last delivered versions of each 
interface are retrieved from the common repository (GlobalWS) and copied in place 
Dependencies. Transition RunEditor executes an editor on the user’s worksta- 
tion, thus allowing the user to edit the module interface. The copies of the other inter- 
faces checked out from the common workspace are also loaded in the editor. As soon 
as the user terminates the editing phase, the new version of the module interface is put 
in place GlobalWS and is made available to all the depending modules. 

When the user requests the termination of the coding activity, transition Term! - 
nateCoding can be enabled to fire. It fires if the module under development has been 
compiled at least once (a token exists in place CompilationResult). After execu- 
tion of TerminateCoding, the guard of transitions EnableTermlnatlon and 
ForbidTermination are evaluated. The guard of EnableTermlnatlon is tme 
only if the dependencies (i.e. the module interfaces which the module under develop- 
ment depends upon) have been officially released, and also the module under develop- 
ment has been compiled for the last time using the final release of each dependency. The 
firing of EnableTermlnatlon enables the execution of EndCodlng that marks 
the last version of the module under development as final, and terminates the execution 
of the activity. ForbidTermination fires whenever EnableTermlnatlon can- 
not fire. It enables NotlfyError that sends an error message to the user. In turn, 
NotlfyError inserts the token representing the module under development in place 
ModuleToCode thus enabling the user to issue other editing and compilation 
requests. 

6.4A.4 Mapping SPADE on the Proposed Framework 

In this section we map the SPADE architecture and philosophy on the framework pre- 
sented in this chapter. In particular, for each of the layers of the framework, the corre- 
sponding SPADE elements are highlighted. 

Repository; SPADE relies on the O2 database system for storing both process model 
descriptions and process artifacts. SPADE users do not interact directly with O2, but 
they have visibility on its mechanisms in two cases: 



GlobalWS 




Figure 6.10 Invocation of two active copies of the coding activity 
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a) In the definition of ProcessTypes and of guards and actions of transitions. In this case 

they exploit the O 2 C language constructs. 

b) During the execution of transitions. Each transition, in fact, executes as an ACID 

transaction exploiting the transactional mechanisms offered by O 2 . 

Workspaces; In general, a workspace is modelled as a place in a SLANG model. As 
shown in the example of Section 6.4.4. 3 , places can be either private to an activity or 
shared among activities. In this last case, each sharing activity can read and update the 
contents of the place. Thus, a common workspace can be naturally implemented with a 
shared place linked by one or more activity invocations. 

Transactions and Knowledge; The granularity of an atomic event in a SLANG 
model is that provided by the transition construct. The process engine assures that all 
the transitions that do not involve external events are ACID transactions. SLANG does 
not offer any primitive mechanism for long or nested transactions. However, such 
mechanisms can be programmed. From the invoking activity viewpoint, an activity can 
be viewed as a nested transaction, which in turn may contain both transitions and other 
activity invocations. In addition, it is easy to add to each activity a net fragment that 
implements any consistency check before enabling the termination of the activity. In the 
example (see Figure 6.9), such consistency checks are enabled by the firing of transition 
EndCoding. They are needed to verify that the implementation of a module relies on 
the final versions of all the modules it depends on, and not on some temporary release. 
This technique can be combined with shared places that can be used by one activity to 
publish the intermediate results of its enactment. Note that SPADE requires an explicit 
management of consistency and cooperation issues because these “high-level” concepts 
are not native to the system. Other systems may not require the process modeller to pro- 
gram these parts of the behaviour of the model or they may provide a means to express 
constraints in a declarative language. The choice of the SPADE system clearly favours 
flexibility and simplicity, but at the cost of a more detailed model specification. On the 
contrary, other approaches reduce the process modeling efforts, but at the cost of 
reduced flexibility. 

Interface; The interface layer manages the interaction between the process engine 
and the human agents who are involved in some way in the process enactment. The 
interaction with process users is supported by the SPADE communication interface and 
is always delegated to some tools in the user environment. That is, the user interface is 
a tool that can be controlled by the process model. SPADE provides process modeller 
with a few integration primitives, a basic set of integrated tools, a set of protocol 
bridges, and the libraries that are needed to integrate new tools. Like an event driven 
system, a SLANG model can be programmed to catch a number of events coming from 
the integrated tools (representing user’s actions) and to react to those events according 
to any particular policy. In the example of Section 6.4. 4. 3 the coding activity reacts to 
the users’ commands appearing as tokens in place UserCommand. These tokens ena- 
ble the execution of transitions depending on the user message they encapsulate and on 
the internal state of the process. 
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Interacting with process managers, for control purposes, and with the process model- 
ler, for process debugging, poses different requirements. In particular, it requires the 
ability to examine the evolution of every step of the model as well as its state. This kind 
of deep insight into a model that is being enacted is provided in SPADE by means of a 
privileged system tool called SPADE Monitor. 

6.4.5 Other Facets of Cooperation 

The advanced transactions models presented in this chapter provide good support for 
the execution of activities that require for non real-time coordination and data sharing. 
However, they fail whenever activities like meetings and cooperative editing of docu- 
ments are to be supported. Such activities pose particular requirements on the architec- 
ture of the PSEE. For instance, the PSEE should provide mechanisms with strict 
synchronisation requirements to multicast data among the participants. 

CSCW (Computer Supported Cooperative Working) environments address these 
issues. However, they usually support specific activities and are not well suited when 
such activities need to be executed within the context of a more complex and articulated 
process. SPADE addresses this issue by integrating CSCW tools that extend its cooper- 
ation support abilities to synchronous cooperation [Band96]. 

6.5 Conclusion 

This chapter has illustrated the complexity of cooperation control in software processes 
and the variety of approaches which can be followed to solve the related problems. 

Other work has been done on this topic in the context of Promoter: the EPOS 
approach can be compared with that of ADELE. ProcessWise and SOCCA model coop- 
eration from scratch as SPADE does, but using different formalisms, objects for Proc- 
essWise, state transition diagrams for SOCCA. 
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The Human Dimension of the Software Process 
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7.1 Introduction 

Any model is an abstraction, a selective distillation of reality highlighting those features 
of the world which are relevant to the goals of the modeller. Presenting a partial view 
means, of course, that much of the complexity and detail of the real world is left out of 
the picture. Models of the software process, for instance, have been criticised for paint- 
ing an impersonal, technical picture of software development in which all traces of 
human presence (other than abstract role definitions) are expunged [CurtSS]. But, of 
course, software development is carried on by people, and indeed many commentators 
have taken pains to stress that high performance depends decisively such “people fac- 
tors” [Cons93, DeMa87, Band95, Curt95]. 

In this chapter, we attempt to “rehumanize” the software process by presenting a view 
of software development that highlights the role of people in the process. Such a 
“human-centred perspective” draws attention to a range of key issues for the design and 
implementation of process-sensitive software engineering environments (PSEEs), 
issues which are less visible from a purely technical viewpoint. In particular, there are 
dangers in the process enactment approach which need to be carefully addressed. The 
chapter describes and discusses these “health warnings” and, in part, takes on the role 
of providing a general critical commentary on the process technology paradigm. 

The chapter will proceed as follows. In the first section, we present three case studies 
of software development. These studies emphasise human and organisational aspects of 
the software process; the cases serve to illustrate the kinds of issues that emerge when 
the software process is viewed from a human-centred perspective. In the next section, 
we will review the state of the art of socially-oriented research on the software process. 
Broadly, this research has been carried out within two distinct communities: the MIS 
(Management Information System) community and the software engineering/HCI field. 
In the third section, we will specifically address the design of PSEEs, focusing on user 
interaction and on the capabilities of PSEEs for mediating interpersonal interaction. 
This discussion will be couched in terms of the Dowson framework [Dows94] which 
provides a useful basis for representing the key relationships between human agents, 
PSEEs and process models. 

J.C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 165-199, 1999. 

© Springer-Verlag Berlin Heidelberg 1999 
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The chapter will conclude with a broad discussion of the general implications of the 
“human-centred perspective” for supporting and improving the software process. This 
discussion will address the limitations of the process enactment paradigm and will 
stress the need for greater synergy with cognate research fields (specifically CSCW) 
and for a more “ecological” approach in software process research. 

7.2 Three Organisational Contexts of Software Development 

Although software development takes place in a wide range of social contexts, we will 
follow Grudin [Grud91] in identifying three broad classes of environment. These are; 

• in-house: i.e. when a user organisation opts to develop a system using its own IT staff; 

• contractual: i.e. when a software house is contracted to develop bespoke software 

(this covers the case where development work is “out-sourced” to an external 
agency); 

• product development: i.e. a software house developing products for the open market. 

A case study illustrating each of these settings will now be presented. Each of these 
cases involves the enactment of a process model, in the sense that software development 
in all three is guided by an explicit process. However, the enactment is not orchestrated 
by a “process enactment mechanism” as the term is understood in this book. 

7.2.1 In-house Development in “ACME Stores”: the Fetish of Methodology 

Acme Stores is a well-established “homeshopping” company providing a mail order 
shopping service for a wide range of household items. Acme is an intensive user of 
information technology; IT systems underpin all areas of the business and are abso- 
lutely critical to the efficient operation of the organisation. The Information Systems 
(IS) department in Acme is centrally organised employing around 60 staff. 

In the early 1990s, concern over a number of issues (long lead times for new software 
development, the manpower involved in maintaining legacy systems, the lack of a “user 
orientation” and the need for a “standard approach”) prompted Acme to engage a firm 
of consultants to help develop a new IS strategy. A key recommendation was to adopt 
a structured methodology and supporting CASE tools. Erom a short list of methods, the 
decision was made to adopt the SSADM methodology [Down92] on the grounds that it 
was a mature methodology (the market-leader in fact in the UK) and was well-sup- 
ported in terms of tools, training and consultancy. 

In early 1991, the SSADM project was formally initiated. The plan was to carry out 
a pilot project (a new parcel-tracking system) in order to develop skills and to allow the 
effectiveness of the methodology to be evaluated. Eollowing an intensive training 
period, the project got underway in March 1991. The early days of the project were 
characterised by a number of problems. Many of the original IS staff were unfamiliar 
with techniques such as dataflow diagramming and entity-relationships modelling 
which are integral to SSADM. One symptom of this diffidence was excessive worrying 
about “getting the notation right” and about the aesthetics of the diagrams. The idea of 
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“logicalisation” was also troublesome to many developers. The CASE tool itself was 
sophisticated; learning to use it required considerable effort and commitment. 

As the project progressed, further problems developed. One of the claimed strengths 
of SSADM is its clear prescriptive structure, in which every step in the development 
process is precisely delineated. Many of the developers appeared to relish the rigour that 
such an explicit framework provided. However, it became increasingly apparent that 
the methodology was being followed in a rather mechanical way. Commenting retro- 
spectively, one of the senior developers (MC) observed that: “People became too 
involved with following the methodology and lost sight of what the system was for - 
they became worried about what task to do next... there was a tendency to let the method 
think for them...” 

Concerns on the user side were growing. SSADM places considerable emphasis on 
user involvement, but there was evidence that communication between users and devel- 
opers was obstructed rather than facilitated by the methodology. Users complained that 
they would be presented with large sets of diagrams that they did not fully understand, 
which they were asked to check and sign-off in what was, in effect, a ritual. Users felt 
that they were becoming embroiled in the details of method and were “losing sight of 
the broader context”. One commented “we did not know what we were doing or why 
we were doing it... we felt ourselves becoming lost in the huge structure of the method”. 
An extreme example of this breakdown in communication was the practice adopted by 
some developers of sending documentation for checking through the internal post in 
order to avoid face-to-face meetings. MC commented “a lot of people wanted to avoid 
talking to users. ..They liked to rely on the procedure. It was a defensive attitude... I’ll 
send this out, get on with the next thing, let them see all the work I have been doing.” 

In June 1992, six months after the original deadline, the project was nearing comple- 
tion. At this point, a systematic review of SSADM was instigated. The review identified 
the rigid bureaucratic structure of SSADM as a major concern and called for a radical 
re-evaluation of the methodology to look for ways to improve flexibility and “to extract 
the high value aspects”. The “momentum” created by the methodology was also a major 
concern; this momentum created a strong pressure to sign things off which often meant 
that products were not reviewed properly. 

User involvement was a major issue as a persuasive argument for adopting SSADM 
had been that it purported to promote a more active role for users in system develop- 
ment. In the past, systems in ACME had been developed by the IS department with very 
little reference to users. SSADM was an opportunity to break away from this passive 
role, but in practice this higher level of involvement had not occurred. Although user 
managers had sat on the project steering group, these meetings had lacked real sub- 
stance; they were basically a “talking shop”. The review considered how greater 
involvement could be promoted, focusing particularly on the role and responsibilities 
of users (what tasks should users perform? what products should they see? what skills 
do they need to participate effectively?). In the following year, two further SSADM 
projects were initiated which were partially successful, although in practice they paid 
lip service to the methodology. MC described them euphemistically as “pseudo- 
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SSADM” projects. Opposition to the use of SSADM strengthened and the decision was 
finally made to abandon the methodology. 

7.2.2 Case B: Implementing Qnality Management in a Software House 
(Columbine) 

Columbine is a medium-sized systems house, employing around 200 staff on two main 
sites. Much of their business involves writing bespoke software (e.g. financial applica- 
tions) for local authorities; i.e. contractual development in our taxonomy. Quality is a 
key issue for Columbine, indeed it is enshrined in the company’s corporate objectives 
which proclaim the aspiration “to be profitable, to grow through customer satisfaction 
and to work for the customer through quality of service”. The commitment to quality is 
more than empty rhetoric. Three years ago. Columbine decided that they would imple- 
ment a comprehensive quality system and to apply for accreditation under the TickIT 
scheme, an initiative set up by the Department of Trade and Industry in the UK to pro- 
mote improved standards of software quality by providing an accredited route to 
ISO9001 certification. 

The quality project began in January 1991 with the setting up of a Quality Team 
involving representatives from all business areas, led by a Quality Sponsor who sat on 
the board of directors. The Team worked on each aspect of the software process in turn 
(e.g. user documentation, project management, test procedures, version control). In 
each area, far from a paucity of formal documentation, a formidable amount of paper- 
work (describing correct procedures, recommended form layouts etc.) was unearthed. 
The job of the Quality Team was to review, synthesise and codify this information into 
a procedure manual for each area. 

The next stage of the project was to carry out a comprehensive audit of the procedure 
manuals. A team of internal auditors was set up in order to check on “process compli- 
ance”. This led to an important finding. In the words of a senior member of the Quality 
Team (JC, now the Quality Manager) “we found that the procedures were too restric- 
tive, too black and white... the procedures said ‘do this, do that’, but there were always 
exceptions. We realised that the procedures were too constraining, they reflected what 
we thought we did, not what actually happened. If we had kept it like that we would 
have had a very bureaucratic system”. As a result of the audit, all the manuals were 
reviewed with the emphasis on abstraction and simplification. With each review, the 
manuals became “thinner and thinner... what we ended up with was more a set of guide- 
lines than a set of detailed prescriptions. The more rigid the rules, the more non-com- 
pliance you get!” 

In Columbine it was recognised that creating a working quality system was more than 
a question of writing procedure manuals. Implementation was seen as absolutely cru- 
cial. JC observed; “We needed to educate staff to see the sense of following proce- 
dures”. Implementation involved a series of initiatives: cascade training, impromptu 
audits, quality quizzes, and a quality newsletter. Above all, the involvement of senior 
management was seen as decisive. The managing director herself undertook training as 
an auditor; she led by example by undertaking several audits in person. Through these 
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various means, the project was brought to successful conclusion on time with the award 
of the TickIT accreditation in August 1992. In 1993 Columbine went on to win the 
national TickIT award for their size category. 

The quality management system (QMS) is seen as having significantly contributed to 
Columbine’s business success over a difficult trading period by providing a decisive 
competitive advantage; the company has succeeded in maintaining profitability during 
times of recession and has seen its turnover grow by over 60% since the inception of the 
program. There have been unexpected benefits too. Perhaps the most important deter- 
minant of software quality is having good people on the staff [DeMa87]; having a rep- 
utation for excellence was certainly seen by the company as an effective way of 
recmiting high quality developers. The standardisation of procedures has also eased the 
movement of staff from one area of the company to another and has facilitated the inte- 
gration of short-term contract staff. 

The design and implementation of a comprehensive quality system is a major organ- 
isational effort. Sustaining it requires continuing commitment and active effort. The 
development of a new metrics framework (focusing on customer satisfaction) going 
beyond the traditional software metrics (e.g. lines of code) is a critical part of the new 
quality system. A continuing programme of “quality improvement projects”, in which 
particular problem areas are proposed as areas for improvement, has also been impor- 
tant in maintaining the commitment to quality. Columbine recognise that quality is not 
a passive state; it is a dynamic process. As the Technical Director commented: “quality 
is much more than having a certificate on the wall. We now have a flexible system which 
evolves and which still changes daily... that is a healthy sign”. 

7.2.3 Case C: User Involvement in the Development of a Medical Workstation 

In this case, we turn to the third of our environments, product development. The case 
concerns the development of a medical workstation by a research team in a university 
setting. The key feature of this example is the focus on user involvement, and the inno- 
vative way that the software process was redesigned in order to facilitate the involve- 
ment of medical practitioners in design work. The project in question is known as the 
PEN&PAD project and was undertaken by the Medical Informatics Group (MIG) at 
Manchester University; a full report is given in [Rect92]. 

The starting point for the project was the perceived failure of many commercial prod- 
ucts aimed at supporting the work of doctors. The history of computing in the medical 
area is a chequered one; there are numerous examples, large and small, of systems 
which have failed [Wast87]. Surveys have suggested that doctors are often ill-disposed 
and resistant to computer systems. The researchers attributed this history of failure to 
the lack of involvement of doctors in the development process and for this reason MIG 
sought a user-centred design methodology which would provide a structure in which 
software developers and doctors could collaborate in the design of the workstation. 

Adapting the work of Mumford [Mumf83]and Norman and Draper [Norm86], the 
research group proposed a new “process model” based on iterative cycles of fast proto- 
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typing and formative evaluation. Traditional software process models (V models, 
waterfall models etc.) were rejected as too mechanistic and conservative in character. 
They are well adapted for development in stable domains, but this project involved 
exploring unknown territory. In the sense that MiG’s design process was iterative, it has 
something in common with Boehm’s spiral model [BoehSl]. Boehm’s spiral empha- 
sises “risk reduction” whereas the design process developed by MIG gave pride of place 
to learning. MIG embraced Norman and Draper’ s view of the design process as a radical 
learning process, a transformative process in which an imprecisely understood objec- 
tive is approached through a number of interim solutions, a process in which a progres- 
sively clearer picture emerges often as a result of sudden moments of illumination. The 
rationale of the new process was thus to optimise radical learning. This was achieved 
by incorporating a number of mechanisms for stimulating constructive discussion 
between designers and users, and for sustaining an open and critical attitude over a two 
to three year period. 

The “social design” of the process was of central importance. The social structure was 
based on three main groups. At the core of the process was the software group, made up 
of computer scientists and one medical specialist who was employed full-time on the 
project. Outside this group was an “inner circle” of five family doctors, with an interest 
in computing systems, who provided primary input to the design team. The inner group 
met with the software developers every month in a “requirements workshop”. This 
cyclical interaction was the inner loop of the process. Outside this loop was an outer cir- 
cle of 12 doctors whose role was to participate in major “formative evaluation” work- 
shops every six months. 

Thus the development process involved two inter-digitating wheels of development. 
Roughly every 6 turns of the inner wheel produced one revolution of the outer wheel. 
The first 6 month cycle, for instance, involved a series of requirements workshops 
aimed at defining initial user requirements and outlining possible designs. Subsequent 
cycles were concerned with refining these ideas and developing design solutions with 
increasing degrees of real functionality. 

Requirements workshops were relatively informal; they involved group discussions 
between the inner circle and the software team. Design ideas were discussed on paper 
or mocked up on the screen using prototyping tools. These ideas were then evaluated at 
the formative evaluation workshops. 

The formative evaluation workshops were more formal than the requirements work- 
shops. It was a fundamental principle that they were “owned” by the users, i.e. the outer 
circle. They were run by two consultants (evaluators) on behalf of the users, not the 
developers. The workshops followed a largely regular format. After a brief demonstra- 
tion of the new prototype, the users were divided into pairs and trained in the use of the 
new system. They were then given a number of “evaluation tasks” to carry out using the 
system, which typically took the form of role-playing exercises in which one user took 
the role of doctor and the other, that of patient. Following these exercises, which were 
passively monitored by the developers, the users completed a questionnaire and a struc- 
tured interview schedule. The workshops concluded with a group discussion. 
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The development process completed four complete cycles over the course of the 
project at the end of which a workstation design, radically different from other systems 
available at that time, was produced. The system has attracted considerable interest and 
enthusiasm from the medical profession whenever it has been demonstrated at exhibi- 
tions. The key to the success of the design process was felt to be the formal structure 
provided by the evaluation workshops which allowed the users to express frank and 
open criticism. 



7.2.4 General Remarks on the Cases 

In this section, we have presented three case studies exemplifying each of the three soft- 
ware contexts. The “human-centred perspective” adopted in the studies has brought to 
light a number of key issues concerning the nature of the software process which would 
not have emerged in a more technical treatment. These issues have important implica- 
tions for the support and improvement of the software process. Each of the studies has 
been written from a slightly different perspective and the messages are therefore differ- 
ent, although there are some common themes (e.g. the issue of user involvement and the 
dangers of too much prescription). 

The first case shows up the perils and pitfalls of attempting to improve the software 
process by introducing a rigorous software model. This case study provides a salutary 
“cautionary tale” that having an explicit process model embodied in a methodology is 
not a guarantee of success. What the case shows is that there are potential problems in 
being too prescriptive about “process” and that these problems are a particular risk in 
certain conditions, e.g. when experience with the method is low or when stress levels 
are high [Wast93b]. The new system in Acme was a failure and the SSADM project was 
ultimately abandoned. One of the main problems was that the methodology encouraged 
a rather mechanical approach to development; the bureaucracy of the method seriously 
inhibited creative problem solving and alienated users. Of course, the failure of meth- 
odology in Acme does not mean that methodology will always operate in this pernicious 
way. There is ample evidence, as we will see below, that methodologies are used by 
developers in a much more flexible and pragmatic way, and of course there are situa- 
tions when rigorous adherence to a highly prescriptive, formal process is essential (e.g. 
the development of safety-critical software). 

An important lesson of the Columbine case is that, although explicit procedures (i.e. 
process models) are central to quality, care must be taken that these procedures are not 
too detailed and prescriptive. A process model is no more than a corpus of rules 
designed to regulate behaviour according to some desired goal or goals. In some cases, 
a rigorous set of detailed rules may be essential (the safety critical situation again). 
However, in many situations highly specified, immutable rules are not required and 
there is a danger that a detailed set of constraining procedures may make work impos- 
sible. Two things may then happen. Either the mles will be ignored or they may become 
an “end in themselves” with bureaucratic sclerosis setting in. These twin dangers were 
recognised in Columbine and led them to develop a “minimalist solution” for their qual- 
ity system. Their process models consisted as far as possible of broad, general rules 
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linked to well-understood quality goals. The important thing was that the rules were 
taken seriously and used on the “factory floor”. What does “process enactment” really 
mean: following rules mechanically or taking rules seriously? The latter surely. A 
strong message from the Columbine case is that the committed involvement of top man- 
agement is critical in getting any new process taken seriously. 

In the third case, the prime focus is on the software process itself. The case forces us 
to consider what sort of process the software process is, what the critical ingredients for 
success are, and how the process should be designed to improve outcomes. MIG very 
much viewed the software process from a “human-centred perspective”. They ascribed 
the failure of traditional process models to their marginalisation of users and to an 
underlying engineering metaphor which emphasises technical rigour rather than learn- 
ing. The importance of the human-centred perspective is that it brings human aspects of 
the software process to the fore. User involvement, for instance, emerges as a central 
not a peripheral issue. MIG showed that by designing a process model with user partic- 
ipation and learning as key design aims, they achieved a degree of success beyond that 
attained by the traditional engineering paradigm. 

At this point we will say no more about the implications of these case studies. In the 
next section, we will review the wide and varied research that has been carried out on 
the software development process from a human-centred perspective. Having done this, 
we will turn our attention to the specific question of PSEE design before concluding 
with a more general analysis of the implications of the human-centred perspective for 
the design of tools and methods to support the software process. 



7.3 The Social Dynamics of the Software Process 

The software development process has been the subject of much research. Broadly 
speaking, two communities, the MIS {Management Information Systems) community 
and the software engineering/HCI community, have contributed to our understanding 
in largely complementary ways. In general, the MIS community has addressed the 
development and implementation of software systems in user organisations, typically 
focusing on the broader organisational/managerial dimensions of systems development. 
The second community, made up of software engineers and HCI researchers, has tended 
to concentrate more closely on the software development process itself and on tools to 
improve productivity and quality. Work in these two traditions will be discussed in the 
next two subsections. A third subsection will focus specifically on process modelling 
and enactment, and will discuss the experiences of the Manchester group in these areas. 

7.3.1 MIS Research on the Software Process 

Broadly speaking, MIS research on the software process can be divided into two main 
approaches which have been dubbed the factor and the process paradigms [Newm9I]. 
Of the two, the factor model is the dominant approach. Much of this research has 
focused on the outcome of IT projects (success vs. failure) and has attempted to isolate 
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those ingredients of the development process (e.g. user involvement, top management 
support) that predispose projects to a felicitous outcome. 

Large-scale inter-organisational surveys are characteristic of factor research. Typi- 
cally a large number of organisations are sent questionnaires in which key causal and 
outcome variables are assessed. As an example of the genre, consider the much-quoted 
study of user involvement by Olsen and Ives [OlseSl] in which the hypothesis was 
tested that user involvement predisposes MIS projects to a greater chance of success. 
Careful “operationalisation” of variables is the hallmark of the factor study and Olsen 
and Ives' study is distinctive for their detailed attention to the concept of user involve- 
ment. Participation was measured for each stage in the life cycle using a simple set of 
questionnaire items and another set of items was used in order to measure system suc- 
cess. 1 10 companies were mailed in the study and 40 responded, of whom twenty three 
agreed to participate. Turning to the results of the study, of the 12 measures of user 
involvement only one showed a significant correlation with system success (the degree 
of user involvement in “signing-off’ the project correlated 0.33 with system satisfac- 
tion). 

Complementing the factor approach is a smaller corpus of “process research” which 
has focused on the detailed dynamics of individual projects and has employed qualita- 
tive (interviewing, ethnography) rather than quantitative research methods. A relatively 
recent study by Newman and Noble [Newm90] is typical. This study relates the vicis- 
situdes of a project to introduce a new university admissions system (in “Middleton” 
State University) and focuses particularly on the involvement of users. The new system 
was designed by an external firm. Initially, user participation was negligible. As the 
project progressed, users began to play more of a part. They learned more about systems 
work and they learned more about the system being designed. But this did not lead to 
their welcoming the new system. They opposed it and their opposition became more 
and more determined. When the system was finally delivered, it was uncompromisingly 
rejected, ostensibly on the grounds that it would make work more, not less, difficult. As 
the project progressed, the conflict grew more hostile with both sides taking more 
entrenched, dogmatic positions; users insisted on changes; designers insisted on keep- 
ing to their original design. Rapidly, the situation escalated into a “win-lose situation”: 
reasonable attempts at persuasion and negotiation broke down, threats were made until 
eventually the user manager appealed to senior management who intervened forcing the 
designers to give way. 

Let us now attempt to synthesise what has been learned about the systems develop- 
ment process from the large but somewhat fragmented body of MIS research that has 
accumulated over the last 20 years. We will begin with factor research, which has char- 
acteristically addressed broad empirical associations between antecedent factors and 
outcomes. Although the pattern of results is by no means clear-cut, the corpus of factor 
research has in general demonstrated the relevance of a range of factors to the success 
of systems development projects. Many studies, for instance, have investigated corre- 
lations between success and user involvement. The picture that emerges broadly sug- 
gests that an empirical relationship exists, although the results of individual studies vary 
considerably and often the correlations are weak [Tait88]. Other potential “success fac- 
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tors” have been examined. A relationship between top management support and success 
has, for instance, been established [Doll85, Dor78]. Personality has also been shown to 
be influential; White [Whit84] and Kaiser and Bostrom [Kais82] have shown that 
project teams with a broad range of personality types are typically more successful in 
development projects than those in which a technical style dominates. 

Process studies have provided a complementary set of insights. Studies such as New- 
man and Noble [Newm90] have cogently shown that the software process in user organ- 
isations is a complex, dynamic process in which organisational and political issues are 
often more fundamental than technical ones. Orlikowski has recently shown that the 
implementation of CASE technology needs to be seen primarily as a process of organ- 
isational change rather than the mere installation of new technology. Without this 
broader perspective, there is ample evidence that productivity gains will not be realised 
[Orli93,Vess92]. In a similar vein, Apte et al. [Apte90] has shown, in a case study of 
software re-use in a bank, that the key factor that led to success was the introduction of 
new organisational structures and reward systems that reinforced re-use; new software 
tools were not enough to change behaviour; the main challenges were managerial not 
technical. 

Many process studies have pointed up the importance of organisational politics in 
systems development and how conflict between vested interests is played out in soft- 
ware projects, decisively affecting project outcome. The Newman and Noble study is a 
case in point. Several other celebrated studies [e.g. Mark83, Newm91] have emphasised 
the fundamental role of political context. Markus, for instance, showed in her seminal 
case study of user resistance in the “Gold Triangle Corporation” that the resistance of 
users (divisional accountants) to a new financial system was motivated primarily by 
political interests and not technical deficiencies [Mark83]. The divisional staff felt that 
the new system would, by providing comprehensive and timely information for corpo- 
rate management, severely undermine their influence. 

Process research has led to a number of “process models” of the systems development 
process, using the term in different way from the technical sense in which it is generally 
used in this book. Hirschheim, Klein and Newman [Hirs87] dub the traditional view of 
systems development, the technical perspective. From this viewpoint, the software 
process is seen as fundamentally impersonal and non-political. It proceeds in a smooth 
linear progression from requirements through design to implementation (the waterfall 
model); the general philosophy of design is essentially mechanical-technical, based on 
an underlying engineering metaphor. In contrast, Hirschheim et al. adumbrate a social 
action perspective. From this standpoint, systems development is regarded as a series 
of episodes involving interaction between analysts and users. Design is seen as a dis- 
course. The quality of this discourse is critical: mutual understanding leading to con- 
sensus is regarded as the key to effective design work. Two categories of discourse are 
distinguished by Hirschheim et al.: dialogue “oriented to understanding”, which 
depends upon “ideal speech conditions” (free exchange of knowledge and ideas, an 
openness to critical discussion.) and “strategic dialogue”, in which one party attempts 
to manipulate the other. Hirschheim et al. cite a range of typical manipulative strata- 
gems common in “the discourse of system development”: the withholding of pertinent 
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information; spurious claims of expertise; immunizing certain policies from criticism; 
the “walk through” which becomes the “walk over”. All too often, strategic communi- 
cation dominates in systems development, which in Hirschheim et al.’s view is the rea- 
son why projects so often fail. 

Newman and Noble [Newm90] have suggested four “process models” of systems 
development: the learning model, the conflict model, the political model and the gar- 
bage can. The learning model effectively represent the conventional view of the soft- 
ware process as a cooperative process in which participants (users, analysts, coders) 
strive for mutual understanding and the realisation of shared goals. The conflict model 
indicates that different perspectives will be present in systems development and that 
these differences in worldview can give rise to conflict; however, through constructive 
discussion these differences are resolvable. The political model, on the other hand, 
stresses that some conflicts represent fundamental clashes of interest which can only be 
settled by the brute or covert exercise of power. The garbage-can model states that sys- 
tems development is an entirely irrational process which proceeds more or less in 
brownian motion. Newman and Noble stress that these different models are simply dif- 
ferent perspectives; there is no single truth about the software process. At any time, 
more than one “model” may be operative and over the course of a project one may pre- 
dominate at one time, only to be supplanted by another model subsequently. For 
instance, the learning model may hold sway at the outset, followed by a period of con- 
flict, which in turn may be replaced by a phase in which learning is again the paramount 
feature. 

The “social process model” of systems development developed by Newman and 
Robey [Newm91] is of interest, as it gives central attention to the issue of change. New- 
man and Robey draw on the concept of evolution as “punctuated equilibrium”, the idea 
that evolution, far from being a smooth process of gradual change, is a discontinuous 
process characterised by long periods of stability interrupted from time to time by bursts 
of convulsive upheaval. The social process model characterises systems development 
as a sequence of events made up of two basic types: “encounters” and “episodes”. Epi- 
sodes are periods of methodological stability; encounters are transitional periods which 
mark the beginning and end of episodes, i.e. where a fundamental restructuring of the 
status quo takes place. Newman and Robey distinguish three general types of episode 
typified by the prevailing mode of development: analyst-led, user-led and joint devel- 
opment. They contend that episodes, once established, will tend to persist, reinforcing 
and recursively reproducing themselves, until some critical event (encounter) occurs 
calling the status quo into question. Such encounters (e.g. missed deadlines, user rejec- 
tion) can bring about a radical shift in the prevailing paradigm, e.g the shift from analyst 
to user-led development. 

In general, the view of systems development that emerges from process studies is that 
of a complex social process that is “pluralistic, ambiguous and conflict-laden” 
[LyytSS] . Systems development is revealed not as a pure technical process moving from 
a clear beginning to a clear end. Instead, a darker view of development work emerges, 
of a complex process fundamentally characterised by conflict, ambiguity, flux and 
transformation. In short, the systems development process is a dialectic [Wast93a]. The 
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central idea of this view is that all social phenomena involve a balance of contradictions 
and that all movement evokes counter-movement and is transformed by this negation. 
The master-slave relationship provides a useful reference example. Imagine two indi- 
viduals in a state of rivalry. They struggle and one prevails, enslaving the other. 
Although it now seems that the master is everything and the slave nothing, it is the slave 
who works and by his work, his strength and skill develop, whilst the master becomes 
effete and dependent. Ultimately, the slave rebels and gains his liberation. This “dialec- 
tic of power” describes well the dynamics of systems development in many cases. 
Rewriting the master-slave dialectic with analysts in the part of masters and users as 
slaves, we have a perfect description of events at Middleton State University: a period 
of instability, of analysts taking the whip hand, of users fighting back, gaining skills and 
eventually wresting control. Here we have the three phases of the dialectic: the initial 
movement (the thesis), the resistance to it (the antithesis), the transformation of the ini- 
tial movement and the emergence of the new order (the synthesis). 

Although antagonistic political interests may constitute the primary dialectic, there 
are many other “contradictions” in systems development that shape the large and small 
scale detail of its unfolding development. Bodker [Bodk90] lists a number of conflicts 
on different dimensions (e.g. cognitive, economic) and at different levels (individual, 
group). The contradiction between design and use is a key one. “The artifacts that we 
work with are under constant reconstruction, due to conflicts in the way they are 
applied... The future will always shape itself differently from predicted... We ought to 
think of design as redesign, not as a one-shot process” [Bodk90]. In essence, the dialec- 
tical view stress the ephemeral nature of all human endeavour, the circularity of causal- 
ity, the inevitability of change and the “openness of human systems”. Any attempt to 
“settle things” by defining a process model, a methodology or a specification will 
always be undermined by objections, emergent ideas, unexpected problems, counter- 
proposals, and so on. 



7.3.2 The Contribution of Software Psychology 

The foregoing section has presented the outline of a significant corpus of research 
addressing, in the main, software development in user organisations from a manage- 
ment-oriented perspective which is primarily concerned with the relationship between 
software development and broader features of organisational context. The software 
process has also been the subject of sustained investigation by researchers within the 
HCI and software engineering fields, who have focused more narrowly on software 
development itself. This research has become known in some quarters as “software psy- 
chology” [Schn88]. Software productivity and quality have emerged as central con- 
cerns of this enterprise. Although much of the original work was laboratory based, there 
have been recent calls for more research on software development activities in their 
operational context. It is this “ecological” research which is of primary interest here. 

The need for a new paradigm in software psychology can be traced back to a special 
issue of the Communication of the ACM in November, 1988. An editorial by Schnei- 
derman and Carroll [Schn88], whilst paying tribute to the achievements of the labora- 
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tory tradition, called for a new “ecological” approach to empirical research on the 
software process (i.e. an injunction to study programmers at work in their natural hab- 
itats) and for an approach to the design of tools to support software development based 
on an understanding of the real work practices of software developers working on real 
software tasks. They dubbed this new approach to design, “Ecological Design”. 

Despite this rhetoric, the lack of field-based research on the software process contin- 
ues to be lamented by commentators. [Perr94] observes that studies of the “human 
aspects of programming have relied primarily on student programmers or artificial tasks 
in laboratory settings. Although these have been informative and useful, their relevance 
to large scale software development is being increasingly questioned.” [Vott94] com- 
ments that “few reliable studies have been performed using software developers build- 
ing software products in their organisations”. The new ecological movement has thus 
by no means taken off; field-based studies of software developers remain extremely few 
and far between. In this section, we will review a selection of such studies. 

Perhaps the most influential “field” study of the software process is Curtis's much- 
quoted interview study in which software engineers were questioned regarding key 
problems that were perceived to afflict the process of software development [Curt88]. 
On the basis of these interviews, Curtis et al. identified three generic problems besetting 
the software process: the thin spread of application knowledge in a project (namely that 
any individual possesses only a local, partial view of the whole process); the inherent 
instability of requirements (that requirements inevitably change over the course of a 
project for many reasons: e.g. new insights, misunderstandings, changes in the external 
business environment); and communication failures (arising from the lack of good com- 
munication channels between participants, and differences in the knowledge, values 
and interests of different groups). 

Curtis et al. proposed a “layered behavioural model” of the software process in order 
to describe and understand the nature and the impact of these generic problems at dif- 
ferent behavioural levels, ranging from the individual, through the group, to the com- 
pany as a whole. For instance, the problem of thinly spread knowledge at the individual 
level is essentially a problem of limited cognition, which to some extent can be reme- 
died through improved training and information flow. At the group level, the problem 
presents itself as an opportunity for more knowledgeable individuals (“project gums”) 
to gain power and hence to dominate the group's decision-making processes, often for 
the good as their breadth of vision is essential to provide direction and integration. 

Since Curtis et al.’s seminal study, the ecological approach has proceeded in a desul- 
tory way, with occasional studies appearing from time to time. For instance: [Port95] 
reports a comparative evaluation of code inspection methods which was carried out in 
a commercial environment; and [Perr94] presents a “time-and-motion” study of soft- 
ware work. There is also a smattering of “ecological design studies” where some empir- 
ical field work has taken place to provide a foundation for tool design. These design 
studies will be reviewed in a later section. 
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Two somewhat more substantial studies have recently been described. [Wate95] 
reports a field study of the development of a large financial system in a financial serv- 
ices company. Like Curtis et ah, they identify the “thin spread of application knowl- 
edge” as a key problem; very often crucial knowledge was concentrated in one or two 
“gatekeepers” or “boundary-spanners”. The study also showed that the ability to 
restructure and renegotiate roles and task allocations was crucial to success; the intro- 
duction of a CASE tool seriously disrupted progress because it rigidified formal roles 
and disrupted the informal and emergent division of labour. The recent field study by 
[Walz93] also stresses the importance of “epistemic processes” in software develop- 
ment (knowledge acquisition and sharing); the study estimated that 75% of the effort 
during the design phase in the field study was spent in learning. The study showed that 
this learning process was often highly inefficient; information and design decisions that 
should have been absorbed into the “team memory” were lost or forgotten, with the 
result that “old” problems and issues were repeatedly revisited. 

In recent years, a smattering of so-called “ethnographic” studies of the work of soft- 
ware developers has begun to emerge. Ethnography refers to the attempt by a researcher 
to understand the practices and culture of a social group through a period of sustained 
immersion. Although ethnography has traditionally explored the character of primitive 
societies, it has been applied recently to understand the social organisation of work in 
more familiar domains, with particular reference to the use of technology; e.g. Such- 
man’s celebrated studies of office work [Such83, Such87]. 

[Rodd94] provides a useful review of ethnographic studies of the software process. 
These have certainly contributed some useful observations. [Bans91], for instance, 
studied the use of structured methods in practice, and noted that designers characteris- 
tically depart from prescribed procedures when carrying out their work. Dataflow dia- 
grams, for instance, are seldom used when communicating with users, and designers 
invariably supplement them with a range of other types of descriptions and diagrams. 
Experienced designers treat methodologies in a highly pragmatic way, using different 
methods and tools when it suits them and their problems, using methods selectively 
rather than “by the book”. [Rodd94] argues that systems projects inevitably enjoin a 
departure from the ideals of rationality that are implicit in methodologies. Projects 
invariably impose sub-optimal conditions, i.e. impossible constraints of time, human 
resources and money. Thus skilled designers become experts at “trading off and can be 
seen as pragmatists and satisficers rather than engineers or rational optimisers”. The 
constraints of actual software work mean that it is never possible to be “fully rational”; 
thus the job of developers is to proceed as if following a rational procedure, although to 
a large extent they are “faking it” [Parn86]. 

[Rodd94] points out that in real work environments, a given project is only one event 
in the wider matrix of organisational life. The technical tasks of software development 
represent only one set of concerns, and that other issues often take precedence, e.g. the 
maintenance of civil relationships with colleagues, especially as those involved may 
well have to work together in the future. [Rodd94] goes on to illustrate other areas 
where what really happens falls short of what ought to happen. Post-project reviews, for 
instance, whilst widely recommended as a vehicle for learning and improvement, rarely 
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happen in commercial settings; “the conduct of post-mortems on failed projects is kept 
as minimal as possible, with staff often being reassigned as rapidly as possible and the 
project with its problems buried equally hastily”. 

The work of Anderson, Button and Sharrock [Ande93] provides a good illustration of 
the ethnographic approach. The essential question addressed in any ethnography of 
work is “just how does the work get done”: in other words, what are the problems as 
perceived by participants and how are they dealt with in practice. For instance, Ander- 
son et al. identified two key problems as constituting the essential dynamic of the design 
process for a new product in the company they studied. The first was the design of the 
product itself. The second was the need to initiate production early enough to meet 
aggressively scheduled launch dates. The focus of the study centered on the various 
strategies used by the project team in order to realise the second of these objectives, e.g. 
the need to improvise on formal procedures. Although standard procedures existed for 
product development, these were circumvented by various ingenious strategies, e.g. 
carrying out an informal project “pre-review” which allowed manufacturing to be set in 
train without the need to wait for a full formal review. The general implication of 
Anderson et al.’s work is that, although technical issues ought to take precedence in the 
development process, in practice these issues are often subordinated to organisational 
exigencies. These “facts of organisational life” have profound consequences for the 
designers of support aids, be they methodologies or tools. Methods and tools which fail 
to reflect the expedient nature of design work are unlikely to adopted by developers. 

7.3.3 Process Modelling and Enactment: Some Practical Experiences. 

The Informatics Process Group (IPG) has considerable experience in the area of busi- 
ness process re-engineering [Wast94]. In this section, we will briefly describe some 
areas of our work that have relevance, from a human-centred perspective, for the mod- 
elling and support of the software process. Two areas will be addressed: a) the nature 
and epistemological limits of process modelling and b) the impact of process support 
technologies in the workplace. 

The concept of process modelling refers to belief that software development practices 
can be faithfully represented in a formal notation such that “support environments” can 
be built around this model. Although the modelling concept seems an eminently 
rational idea, in practice it turns out to be somewhat problematic. A project undertaken 
by IPG in “Pineapple Computers” (a large manufacturer of computer systems) provides 
an instructive example of the problems that are common. The aim of the project was to 
analyse and redesign the key processes in the Systems Integration (SI) division of Pine- 
apple. The SI division was made up of two so-called “Open Systems Centres”: one cen- 
tre was based in the north, the other in the south of England. They will be referred to as 
North and South. 

The first stage of the IPG’s methodology iPADM, see [Whit93]) calls for the model- 
ling of extant processes. At South, the exercise was a “primrose path”; a clear process 
explicitly existed and expressing the process formally proved relatively straightfor- 
ward. The contrast at North was stark. One of the investigators commented: 
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“At South the process was clear... here we found ourselves going round and round, 
reading masses of paper, but it was all very high level mission statement stuff. It was 
hard to understand what people actually did. They would say, well I am doing this but 
that's not really part of the process.lt was difficult to make any sense of... we were con- 
tinually coming back to process definition. What was the process all about, what were 
its inputs and outputs? People just seemed to have ideas, to work on them and produce 
a report at the end. We would show a process model to a manager and ask Ts it like 
this?’ They'd say ‘yeah’. A week later we'd come back and show them something com- 
pletely different. They'd say ‘yeah’ again! Eventually we did produce a high level proc- 
ess definition for North. However, when they saw the detailed activity diagrams we had 
produced for South they said ‘that's what we do’ even though it was completely differ- 
ent!” 

Thus the idea that objective process models can be readily constructed is shown to be 
somewhat optimistic. Typically people have trouble articulating just what they do. They 
are not used to reflecting objectively on their work; there is much that is implicit and 
taken for granted which they find difficult to express. The difficulties of “knowledge 
elicitation” are well-known in the expert systems field, and we would do well to view 
process modelling as a problematic “knowledge elicitation process” rather than a sim- 
ple act of description. 

Woolgar [W00I88] identifies what he calls three “methodological horrors” which 
bedevil any attempt (not just process modelling) to construct representations. Indexical- 
ity refers to the radically contextual nature of object-representation links. Inconcluda- 
bility refers to the essential incompleteness of any representation: there is always more 
to be said than can be captured in the representation. Reflexivity attacks the idea that a 
clear distinction can be made between the signifier and the signified, i.e. that the 
description of an object and the object itself mutually constitute each other. To these 
three, we would add a fourth “horror”, the radical relativism of modelling. Representa- 
tion is always an act of interpretation; what is seen depends fundamentally on one’s 
point of view. Universities, for instance, can be seen either as research institutes or 
teaching facilities; process models describing essentially the same superficial activities 
would be quite different according to the perspective adopted. What may seem to be the 
process may turn out to be a chimera. The problems in Pineapple also show up the polit- 
ical nature of modelling. Undoubtedly some of the difficulties arose because the “proc- 
ess actors” saw the modelling exercise as an attempt by managers to find out what they 
did and hence to control their work. Feigned ignorance and dissimulation are classic 
forms of resistance. 

Many of the vicissitudes of modelling boil down to the sheer slipperiness of language 
itself, its ineluctably protean character. Language is not stable; meanings are relational 
not absolute. In Derrida’s terms, there is always freeplay, no centre, no firm place to 
stand [Sam88]. Meaning is always deferred, scattered across chains of signifiers, at our 
fingertips but always beyond our grasp. Meaning is not simply and immediately present 
in signs (a process model is a complex sign); the meaning of a sign is what it is not as 
well as what it is. Meaning is a kind of “constant flickering of presence and absence”. 
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It is instructive to note that IPG’s eventual proposals for process improvement in 
Pineapple, whilst based initially on the modelling/enactment concept, ultimately moved 
on from this paradigm. The report recommended that fundamental re-engineering of the 
division’s processes was required rather than the installation of process support tech- 
nology. The aim of these changes was to promote the more effective acquisition and 
codification of “systems integration” knowledge. An important recommendation, for 
instance, was to improve links between the Open Systems Centres and systems integra- 
tors in the field, i.e. the engineers responsible for installing and supporting systems on 
customer sites. Greater participation in “bid support” was another measure recom- 
mended along the same lines. It was also suggested that more configuration testing 
should be carried out on customer sites. 

Despite the problems of modelling, let us assume that a model has been built and that 
there is some confidence about its veracity. What is the evidence that building a support 
environment around this model will actually lead to an improvement in the process? 
This an absolutely central question for the “process approach”. However, the little evi- 
dence that we have indicates that there are severe limits to the approach. Consider 
another example from the IPG’s portfolio of cases. This example involved the imple- 
mentation of a workflow system (based on PSEE technology) in the customer services 
division of a systems house which we will dub “Orchid Systems”. 

The project focused on the User Support process and was a challenging one. User 
Support was a substantial enterprise involving many staff and there was a well-defined, 
complex process for dealing with customer problems, documented in a detailed set of 
“work instructions”. The key design task for the development team was to model this 
process. A process support system enacting the model was then developed and piloted 
in one of the work-groups. The role of IPG was to evaluate the new system. 

The attempt to introduce the system met with fierce opposition. The users (the support 
staff) complained that the system was too prescriptive; they felt that it attempted to 
impose a straitjacket on them which forced them to follow the work instructions “to the 
letter”. One user commented, somewhat drolly: “Your system has been designed to be 
idiot-proof, the trouble is we're not idiots”. IPG’s investigation revealed that, although 
many months had been spent writing the process model and building the system, very 
little time had actually been spent talking to end-users, watching and assessing what 
they really did. The basic problem lay not in any weakness of the modelling language 
which had fatally limited the validity of the model, but derived from the naivete of the 
developers who had assumed that the end-users followed the work instructions in a 
largely mechanical way. 

In reality, although procedures certainly existed in User Support, they did not deter- 
mine the work that was done; applying the procedures involved considerable judge- 
ment, flexibility and inventiveness. A process model, as we have said, is a corpus of 
rules. Working according to the rules does not mean following them to the letter. IPG’s 
ethnographic analysis of work in User Support showed that the formal rules were insuf- 
ficient on their own to cope with the exigencies thrown up in the course of a day’s work. 
“Workarounds” were commonly employed where the formal procedures were either too 
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restrictive or where no clear procedures existed. There were many examples where rules 
were technically broken: for instance, when a member of staff left a job at the top of the 
“job queue” to a colleague who was more experienced with that kind of problem. This 
was wrong according to the rules (the process model) which said that the job at the head 
of the queue should always be dealt with first, but was clearly done in the best interests 
of the customer. 

In short, by basing the system design on the procedure manual rather than real prac- 
tice, the designers had attempted, as Sheil has pithily put it, “to automate a fiction” 
[Shei83]. The problem lay in putting too much into the model and not leaving enough 
discretion to the “process actors”. This is a ubiquitous problem in process modelling/ 
enactment; we shall return to it in the following section. In part, the motive to “control 
the process” was a deliberate intention. One of the managers observed that he had 
wanted to tie his staff down, “to pin them to the floor”. Flexibility and initiative were, 
however, the key to efficient and effective performance not slavish conformance to 
process. Version one of the workflow system was rejected and was withdrawn. A less 
prescriptive version was developed with more user involvement. This version proved to 
be more acceptable but the project was subsequently discontinued. 

7.4 The Human Role in the Software Process: 

Dowson’s framework 

In the preceding two sections, we have reviewed a broad cross-section of research on 
the social aspects of the software process. The research is diverse in content and in 
methodology: a rich melange of topics has been tackled using a wide variety of scien- 
tific paradigms, principally: interview-based field studies (e.g. Acme Stores, Colum- 
bine, and [Newm90, Curt88], ethnographic process studies [e.g. Mark83, Orli93, 
Wate95, Ande93] and cross-sectional surveys [e.g. 01se81]. In this section, we will turn 
our attention to the specific question of the PSEE design. Our discussion will be formu- 
lated in terms of the “Dowson framework” which provides a useful schema for concep- 
tualizing the “human role” in the software process and for crystallizing key design 
issues for process support [Dows94, Arba93, Allo94b, Eern93]. 

7.4.1 Dowson's Framework 

Dowson's framework distinguishes three different domains in relation to the software 
process [Dows94]. It establishes a conceptual separation between process definition, 
process performance and process definition enactment. The domain of process defini- 
tion contains characterisations of processes or fragments of processes, expressed in 
some notation, in terms of how they could or should be performed. The domain of proc- 
ess model enactment is concerned with what takes place in a PSEE to support process 
performance. The domain of process performance encompasses the actual activities or 
actions conducted by human agents (project staff including developers, managers, etc.) 
and non-human agents (computer programs, tools). The three domains interact as fol- 
lows. Software process modelling will result in software process models, i.e. the first 
domain; their “execution” by an enactment mechanism, i.e. the second domain, will 
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provide assistance to process performance, i.e. the third domain. The Dowson frame- 
work is summarised in Figure 7.1. 



Process Definition Domain Process Performance Domain 




Figure 7.1 Software process domains (after Dowson) 



In order to establish a clear taxonomy, it is necessary to clarify the nature of human 
agency within the Dowson framework, i.e. to distinguish between the various roles 
played by human actors in the software process. Four classes of “software process 
actors” can be distinguished (see glossary): the process designer, the process manager, 
the process agent and the end-user. Of course, these are abstract roles rather than con- 
crete people. In practice, a given individual may fulfil several of these roles. 

The process designer acts in the process definition domain. S/he defines generic proc- 
ess models and manages their evolution. These models describe a global development 
strategy independently of a specific context or project [Bena92]. Many people poten- 
tially fill this role in the real world: the creator of a methodology, the technical strategist 
in a software house or consultancy. The process manager acts in the process definition 
and the process enactment domains. S/he adapts generic process models to a specific 
project and instantiates them in order to obtain an enactable model. In a real working 
environment, this job could be done by a project manager working in conjunction with 
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the technical director of the company. The process agent acts in the process perform- 
ance domain. S/he may be the project manager, programmer, systems analyst, quality 
auditor, tester, configuration manager. The end user acts in the process performance 
domain. S/he is the “customer”, i.e. the user of the product which is developed. 

Process performance brings all three domains into play: all the agents mentioned, 
human and non-human, participate in a dynamic flux of interaction (communicating, 
coordinating, negotiating, advising, questioning, etc.) within and across the boundaries 
of the three domains. This section is concerned with design issues relating to these pat- 
terns of interaction. We will distinguish two kinds of interaction: user interaction 
(which designates interaction between the process agent and the enactment mechanism) 
and interpersonal interaction (which primarily designates interaction between process 
actors). 

7.4.2 User Interaction 

User interaction means interaction between the enactment and performance domains, 
i.e. between the process agent and the enacted process model. User interaction typically 
refers to an individual activity that requires only one human being, e.g. editing a mod- 
ule, reading a document [Gruh93]. This interaction is bidirectional. Enactment-to-per- 
formance interaction (E>P) refers to the influence of the process enactment mechanism 
upon process actors in order to regulate the way in which a process is performed. Per- 
formance-to-enactment interaction (P>E) refers to the reciprocal link between the proc- 
ess agent and the enacted model in order to provide feedback on the current status of the 
operational process. Both flows of “interaction” raise key design issues. 

The E>P interaction directly raises what we believe to be a key issue for PSEE design, 
namely the “control” question: in short, which is to be master, the PSEE or the human 
actor? This issue is highlighted in the concluding chapter and it figures as a key concern 
in the writings of other authors involved in this book [e.g. Band95]. This power rela- 
tionship can a take a variety of forms: from a highly prescriptive form where the enact- 
ment mechanism effectively dictates actors’ actions, to a much softer form (which we 
would call the proscriptive mode) in which agents have much greater discretion about 
what to do next and the enactment device operates in a largely advisory role. Dowson 
and Fernstrom [Dows94] have identified a spectrum of possible interaction styles: pas- 
sive guidance, where the enactment mechanism provides actors, on request, with infor- 
mation that helps them carry out the process; active guidance, where the enactment 
mechanism provides help without being solicited by the process agent, i.e. the process 
model specifies when and how this help is to be provided; process enforcement, where 
agents are forced to perform a part of the process in a specific way, e.g. by controlling 
their access to data or tools; process automation where some part of the process is auto- 
matically performed under the control of the enactment mechanism without any partic- 
ipation by the process agent. 

The major question for the first sense of user interaction, i.e. enactment to perform- 
ance, is to determine, while taking into account human nature and social processes, 
which kind of interaction a PSEE should support, i.e. prescriptive, proscriptive, passive 
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or active guidance, or a combination of these possibilities. The problem is to determine 
the appropriate mode and to indicate in the process model that, for instance, passive 
guidance is required for some process steps, active guidance or enforcement for others, 
etc. We concur with others [e.g. Band95] that there is no generic solution to this prob- 
lem and that the level of enforcement must be designed on a step by step, case by case 
basis as an explicit part of the process model. There is no sense in attempting to specify 
a single enforcement paradigm as a fixed property of the PSEE. 

Although the issue of where to place the “locus of control” cannot be reduced to a 
simple formula, some general precepts may be derived from the behavioural research 
that we have reviewed. The main implication of this research is its revelation of the dan- 
gers of the prescriptive approach. The most obvious reaction of human actors to an 
overly “authoritarian” PSEE will be to reject it, much as the customers services staff 
rejected the PSEE in Orchid Systems. There are at least two reasons why strong PSEE 
control will be rejected: the first is political (i.e. autonomy is infringed). The second is 
more subtle and is cogently revealed in the Orchid case which shows that even routine 
work has an open, problem-solving nature such that all eventualities cannot be specified 
in advance. Thus the procrustean attempt to impose a process model runs the risk of 
obstructing the free play of expediency and ingenuity that ethnographic studies have 
shown to be the essence of efficient work. 

Rebellion is one adverse reaction. Its mirror image, subservience, is also possible. 
Eaced with an autocratic regime, workers may simply “work to rule”. In other words, 
they may react with slavish conformance. That this sort of reaction can occur is well 
illustrated in the Acme case, where “process actors” (analysts and end-users) abdicated 
personal responsibility and instead simply followed the process in a blind mechanical 
way. This case is not an isolated instance. Based on her work in the government sector, 
Damodaran [Damo93] has observed that systems developers have a strong tendency to 
take a “checklist” rather than a critical approach; following the method rather than 
thinking for yourself provides “political protection” should things go wrong. Middleton 
notes that staff often do not fully understand the rationale of the methods they use and 
often go through the motions, “learning it by rote as an excuse not to think” [Midd94]. 
DeMarco and Lister [DeMa87] have noted that detailed methodologies stifle creativity 
and reduce, rather than increase, productivity. They quote a developer on a failed 
project as saying: “By March we had been doing this for nearly two months. I couldn’t 
see how it was helping us in any way, but George kept reassuring us that it was. He said 
that we should all trust in the methodology and that it would all work out in the end”. 
Of course, it didn’t! In other words, this second form of pathological reaction is thus a 
very real problem. 

The P>E interaction is equally problematic. Given that the enactment domain cannot 
determine everything that happens in the surrounding work environment, it needs to 
gain knowledge of these external developments if its internal “image of reality” is to 
remain consistent with the state of affairs within the performance domain. This feed- 
back is critical; it is the only means to ensure that the enactment and the performance 
domains are in alignment, i.e. that the “states” of these two domains are as consistent as 
possible. Therefore, there is a high degree of dependence on process actors for appro- 
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priate feedback about the state of process performance. The quality of this feedback 
will, of course, be subject to the vagaries of human nature. Process agents may some- 
times forget to provide the needed feedbacks, or provide erroneous information; they 
may be unsure about the validity of intermediate results or they may bypass the points 
at which feedback is expected. 

It is important to distinguish two sorts of feedback, which we will designate first and 
second order feedback. First-order feedback is simply a report of progress in accordance 
with the prescribed model; second-order feedback, on the other hand, refers to local 
changes that have been made to the process in response to practical exigencies (let us 
call this “process adaptation”). The latter feedback indicates that the enacted process 
model itself requires change, and there may also be a need for this information to feed- 
back to the definition domain as it may suggest weaknesses in the generic model. We 
will say more on this second form of feedback in the next section. 

Effectively, first-order feedback corresponds to the sort of function that is provided 
by a management information system. The inherent problems of designing and imple- 
menting effective MISs have been extensively investigated by MIS researchers. The 
picture that emerges is highly problematic. The conventional view of MISs has been 
dubbed by Lyytinen [Lyyt87], the “reality-mapping” paradigm, i.e. the view that an 
MIS embodies a model (a representation) of the real world. The key problem is to 
ensure that this model is veridical, i.e. that it reflects an accurate picture of the outside 
world. This requires users to enter valid information in a timely way. All too often, this 
does not occur; there is copious evidence that such information systems are overtly and 
covertly undermined. Wasted, for instance, has discussed this problem at length in the 
health care sector where MISs have a long history of failure [Wast87]. 

There are many reasons why an MIS is not kept up to date with accurate information. 
The first is that the MIS is perceived as part of a management control system and is thus 
resisted for political reasons. A second reason is that there is often little incentive for 
workers to enter information because the MIS provides them with little help with their 
immediate concerns. In the health service, for instance, a constant complaint of medical 
staff is that they are obliged to spend more and more of their time “entering data”, yet 
this information is of no use to them. Wasted [Wast87] concludes that only information 
systems which provide an immediate operational benefit have any chance of success. In 
our area, this means that the PSEE must be fully integrated into the work activities of 
the process agent and must help them do their joh better. A PSEE that operates simply 
as a remote control system will be unlikely to succeed. 

7.4.3 User Interaction, Learning and the Meta-Process 

Thus far, for convenience, we have treated the two “arcs of interaction” between the 
performance and enactment domains as independent processes. It is somewhat more 
insightful to see these two unidirectional links as making up two elements of a dialec- 
tical interaction between the process model and reality. Chapter four argues that this 
interaction provides the essential dynamic force for process evolution; contradictions 
between the process model and reality (signalled through what we have called “second 
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order feedback” in the preceding section) provide the impetus for change and improve- 
ment in software processes. A critical issue is to achieve harmonious and coordinated 
evolution of process models and the real-world processes that they purport to represent; 
the concept of the “meta-process” denotes such a higher-order process for achieving 
disciplined, managed evolution. 

The meta-process is essentially a “learning process”. The world of software develop- 
ment is an “open system”: change and uncertainty are inevitable. The key to effective 
performance is thus the ability to adapt means (models) to specific circumstances, and 
to improve process models in the light of experience. Process models “prescribe” a 
methodology; second-order feedback from the performance domain indicates practical 
adaptations and possible deficiencies. Models may thus be seen both as prescriptions 
and as an evolving body of experience. Much more is said on this subject in Chapter 4 
and we will return to this theme in the next section of this chapter. 

Here we will restrict ourselves to a couple of points. The first is to draw attention to 
two types of learning implicit in the Dowson framework: enactment domain and defi- 
nition domain learning. The former refers to incremental changes to the process model 
in the enactment domain arising from the need of process agents to adapt the model to 
local circumstances. The latter refers to change in the definition domain arising from 
persistent problems in the enactment and performance domains reflecting some basic 
inadequacy of the enacted model. This form of learning corresponds to the situation in 
which, for example, development of a new version of a methodology is stimulated by 
persistent complaints from users about deficiencies in the current version. Thus we see 
the relationships between the three domains in Dowson’s framework as consisting of 
two interlocking dialectics. The interaction between the enactment and the performance 
domains serves as the primary dialectic. Through contradictions between the normative 
model in the enactment domain and practical experience in the performance domain, 
weaknesses in the software model are identified and remedied. Should these problems 
be persistent and fundamental, then feedback to the definition domain (the secondary 
dialectic) will lead to refinement and reformulation of the generic model. 

The second point returns to the issue of user interaction design. The learning perspec- 
tive suggests that, except perhaps in critical situations where a strong lead be supplied 
by the PSEE, the E>P interaction style ought in general to be supportive but critical (the 
active guidance mode). The role of the PSEE should be to guide the process agent 
through the intricacies of a complex development process indicating what steps should 
or could be done next, and providing help and explanations, perhaps also constructively 
questioning actors’ decisions. Regarding the P>E link, it is vital that the information 
gathered by the PSEE is seen by process agents as providing a rational basis for process 
improvement and evaluation, not as a management control system. 

7.4.4 Interpersonal Interaction 

Interpersonal interaction (Figure 7.2) refers to the interaction between several process 
actors, for example two programmers discussing a design document, a code inspection 
meeting etc. [Gruh93]. Interpersonal interaction can be considered to be of two kinds: 
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Formal interpersonal interaction. An interpersonal interaction is called formal when 
it occurs following well defined and formalised protocols. Communication protocols 
may be described either via a process modelling language, or a natural language. For 
example, we can imagine a kind of “protocol communication manual” that describes the 
communication strategy and guidelines of a given firm. This manual contains informa- 
tion such as: administrative hierarchy between actors (e.g. if a programmer encounters 
problems, the company’s rules requires that he first inform the design engineer), how 
often review meetings must be held etc. 




Figure 7.2 Patterns of social interaction in the software process 



Informal interpersonal interaction. An interpersonal interaction is called informal 
when it is not regulated by any kind of formal communication protocol (e.g. using 
phone calls or electronic mail, exchanging ideas or information in the coffee room). The 
vast bulk of interactions in a software project will be of this nature. They take place 
entirely within the performance domain (Figure 7.2), i.e. they are not mediated or reg- 
ulated by the enactment mechanism, nor are they forecast in the process definition. 
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There is certainly an important place in the software process for tools that support 
interpersonal activities. Indeed, the CSCW field [Baec93] has been the source of many 
innovative developments in software process support in recent years (see next section). 
The primary questions are how much interpersonal interaction should be mediated 
through the PSEE and to what extent this interaction should be actively orchestrated by 
the PSEE. Again, there are no hard and fast answers. Structuring communication cer- 
tainly has advantages, and indeed it is the potential of computer-mediation to provide 
structure that has been the impetus behind many of the early developments in CSCW, 
e.g. the widely-known Cognoter tool developed in Xerox’s Colab [Stef87, Tata91]. 

Although the imposition of structure through computerised mediation has been 
shown to improve the quality oi formal group processes (e.g. the Delphi process), there 
is also evidence that structure is resisted by participants. The Cognoter tool, for 
instance, failed for this reason [Tata91]. Another problem with attempting to formalise 
interaction is the danger that process models will grow out of control [Bena92] and 
indeed it is debatable whether all interaction patterns can be specified in advance even 
if this were to be desirable. Thus we may say that there are advantages to be gained from 
formalizing certain aspects of the group process in software development, and there is 
a case to be made for incorporating such formal structures in the process model and 
thereby the enactment domain. However, there is also a need to proceed carefully in this 
area and to avoid an over-interventionist approach. 

Eor informal interaction, the situation is clearer. Here the emphasis should be on pro- 
viding communication facilities in the performance domain (email, bulletin boards etc.) 
to support networking and the exchange of knowledge. These interactions are crucial to 
the success of a project as they enable information and expertise to be exchanged 
[Wate95]. There are great benefits to be gained by supporting and fostering such com- 
munication and some limited formalisation could be of benefit. Maintaining a database 
of key skills, for instance, would provide individuals with guidance as to who to turn to 
for assistance. On the other hand, we should be keenly aware of the dangers of disrupt- 
ing such informal activities through the direct or indirect effects of technical or organ- 
isational changes, i.e. to beware of the sorts of problems that [Wate95] found in their 
field study of CASE. 



7.5 A Human-Centred Approach to Software Process Support 

Thus far in the chapter, we have reviewed the “state-of-the-art” in socially-oriented 
research on the software process and considered some specific implications of this 
research for the design of PSEEs. A number of themes have arisen in the course of these 
sections, albeit in an inchoate way. These themes have significant general implications 
for the design of tools and methods for the improvement of software processes, and in 
this penultimate section, a synthesis and integration will be attempted. 
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7.5.1 The Need for an “Ecological Approach” in Software Process Research 

The social sciences are empirical sciences. They generate theoretical explanations for 
human behaviour which stand or fall on the basis of empirically verifiable predictions. 
An important contribution that the “human-centred perspective” thus makes to software 
process research is its empirical orientation. This can be translated into an insistence 
that the design of new technologies should be grounded on a rigorous understanding of 
the real work practices of software developers. In essence, this is the position argued by 
Schneiderman and Carroll [Schn88] in their call for an ecological approach to the 
design of tools to support software development. This “Ecological Design” approach 
has inspired a number of innovative ways in which design activities can be supported. 

One of the earliest examples is Rosson et al.’s [Ross88] empirical study of user inter- 
face designers. From their field work, Rosson et al. identified the process of “idea gen- 
eration” as being at the heart of design work and the authors examined the techniques 
for “idea generation” that were actually practised by designers (e.g. task scenarios, 
direct user observation). On this empirical foundation, a number of areas where soft- 
ware tools could provide assistance were suggested. Another notable ecological study 
is the attempt by Soloway et al. to design software documentation based on an empirical 
understanding of the cognitive strategies employed by programmers engaged in soft- 
ware maintenance [S0I088]. Soloway et al. set out to understand what aspects of pro- 
gram comprehension were difficult and to base their proposals for support tools around 
these weaknesses; this is the very hallmark of the ecological approach. Based on a lab- 
oratory study using “real” IBM software developers and their field observations of code 
inspection meetings. Soloway et al. identified the “delocalized plan” as a common 
source of problems in program comprehension and therefore as an insidious threat to 
effective software maintenance. A “delocalized plan” refers to the situation in which 
“pieces of code that are conceptually related are physically located in non-contiguous 
parts of a program”. Delocalized plans typically arise as the result of short term optimi- 
sations during coding; they are a fact of programming life. Soloway et al. go on to pro- 
pose a number of interesting ideas for software tools to help deal with them. 

It is nearly ten years since Schneiderman and Carroll’s “ecological exhortation”. In 
that time, however, very few ecological studies have been carried out [Vott 94 ]. Even in 
CSCW, which is closely associated with the ecological credo, the amount of empirical 
work that exists is limited, small-scale and often laboratory-based. More empirical 
research on the software process in real field settings is therefore urgently required. As 
Rosson et al. observe: “In order to create effective tools, we must follow the same strat- 
egy necessary for the design of any other software system - with the study of target users 
and their tasks, in this case software developers and their design practices. This may 
seem an obvious approach, yet there are remarkably few examples in the literature” . In 
a similar vein, Twidale has commented that “while we recognise that most design 
involves collaboration, our understanding of its nature as a cooperative process is lim- 
ited. Worse, our intuitions as to the support required may be flawed. Consequently, tool 
developers must discover the nature of the design process” [Twid 93 ]. 
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Potts [Pott93] has lamented that research in software engineering is all too often solu- 
tion-driven rather than problem-focused; as a result, innovative developments in soft- 
ware engineering have had limited influence on software practice. In order to promote 
greater relevance and to facilitate “technology transfer”, Potts calls for shift away from 
the traditional “research-then-transfer” paradigm to an “industry-as-laboratory” model 
in which the realms of practice and research are brought closer together with research 
firmly based on real case studies (in effect an “action research” model). Closing the gap 
between research and practice is vital to the future well-being of software process 
research. A joint study announced recently by the Software Engineering Institute in 
conjunction with Nolan and Norton to gather information from software companies 
with experience of software process automation thus represents a welcome and prom- 
ising initiative in this direction. The emphasis on case studies in the future plans of the 
Promoter group is also a significant development in the same spirit. 



7.5.2 Synergy with Computer Supported Cooperative Work 

The “human-centred perspective” emphasises forcefully that software development is 
a cooperative social process in which the interaction between team members is the key 
to success [Band95]. Cooperation is a complex construct which subsumes a number of 
distinct aspects: coordination (the scheduling of asynchronous activities), communica- 
tion (the exchange of information and expertise), and collaboration (joint problem-solv- 
ing in a spirit of partnership and mutual respect) [Band95,Yang95]. Because its inherent 
emphasis is on “process”, software process research (and the technologies that it has 
spawned) has tended to stress the first of these dimensions: coordination. The rationale 
of PSEEs is to improve coordination: process models indicate what task is to be done 
when, by whom and with what tool. The enactment of these models by an enactment 
mechanism thus ensures that the activities involved in software production are properly 
coordinated according to the blueprint expressed in the process model. 

This emphasis on abstract processes and coordination tends to downplay the impor- 
tance of “people factors” in software development. The two other aspects of coopera- 
tion (communication and collaboration) put more stress on the human role. The field of 
Computer Supported Cooperative Work [Baec93] has generally emphasised these 
aspects of cooperation more than the process-oriented, coordinative dimension. This 
complementarity of interests suggests that research on PSEEs will be enriched by more 
cross-fertilisation with CSCW [Band95]. Bandinelli et al. argue, for instance, that the 
choice of interaction metaphors in PSEE research has tended to be somewhat limited. 
The orientation to process has typically led to the adoption of the “task agenda” as the 
natural interface metaphor in many PSEEs, e.g. ProcessWise and SPADE. CSCW, in 
contrast, has generated a diverse range of novel and sophisticated interface metaphors. 

Since its inception, CSCW has been firmly associated with the need to study work in 
a naturalistic way using techniques such as ethnography. CSCW has stimulated a fresh 
look at the nature of human work in organisations and on the possibilities of technology 
to support and improve individual and group effectiveness. CSCW has produced a 
number of innovatory tools for supporting group activities and it is clearly important 
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that PSEE research takes account of these developments. Bandinelli et al. argue that 
extant PSEEs typically provide little support for “synchronous cooperation” whereas 
this is an area which is strongly represented in CSCW, where many tools have been 
developed based on the shared workspace paradigm. CSCW has developed a number of 
innovatory tools of a general nature which have clear application to software develop- 
ment (e.g. co-authoring tools, meeting support tools). As well as these generic tools, 
CSCW has also produced a number of specific tools for supporting software work. 

The work on “Design Rationale” provides a good example [Carr94, Macl90]. This 
work is rooted in the idea of design as a collaborative group activity that unfolds with a 
good deal of haphazardness over time.The essence of design rationale is to provide a 
medium for recording the informal design ideas, decisions, interim concepts and group 
interactions that together make up the history lying behind a given design. Capturing 
not only the formal products of design but also the processes that resulted in those prod- 
ucts, has many potential benefits, e.g. the record helps to explain and document the final 
design and provides a basis for the improving the way in which the design group work 
together [Carr94]. Several tools based on the design rationale concept have been devel- 
oped. “Raison d'etre”, for instance, is a hypermedia database which provides a reposi- 
tory of video clips containing stories and personal perspectives of design team members 
[Carr94]. IBIS is another well-known example [Yake90]. 

PSEE and CSCW research are complementary. Whereas PSEE research deals with 
technologies to coordinate activities stretching across the entire length of a complex 
production process, CSCW emphasises people and the need to provide tools to help 
them work together more effectively on individual tasks. A key issue for PSEE research 
is thus to provide mechanisms for accommodating CSCW tools within software engi- 
neering environments. Bandinelli et al. illustrate how a synchronous CSCW tool {Imag- 
ineDesk) can be successfully integrated in SPADE [Band95]. As well as providing 
tools, CSCW is also a fertile source of innovatory ideas regarding interaction metaphors 
and indeed metaphors for modelling cooperative processes. The language-action para- 
digm, in which processes are modelled as conversations, is an instructive example 
[Wast91]. By inspiring ethnographic studies of group work, CSCW has also led to a 
number of important insights into the nature of group work (see next section) which are 
very relevant to our field, and has stimulated the use of a broad range of psychosocial 
methods for studying group behaviour from which empirical software process research 
can usefully benefit. 



7.5.3 The Limits of the Process Enactment Paradigm 

One of the central axioms of the “process approach” is that by strengthening the rigour 
of development, we will improve the quality of software artifacts and the productivity 
of software developers. To a large degree, this depends on the view that is adopted of 
the software process. Kendall and Kendall [Kend93] have argued that the system devel- 
opment process can be viewed from several angles by bringing to bear different meta- 
phors; system development can be see as a “journey”, as “warfare”, as a “zoo”, as a 
“family”, as a “game”. The conventional view is to see it as a deterministic engineering 
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process - the metaphor of the machine. The view that the software process can be 
improved through increased process rigour (e.g. through structured methodologies) is 
clearly based on this metaphor. 

Given our foregoing advocacy of empiricism, we may generally ask whether there is 
any evidence that methods based on this engineering paradigm have been success- 
ful. There is in fact an astonishing paucity of empirical evidence on this critical point 
[Wyne93]. Research on the practical efficacy of structured methods, for instance, is 
almost non-existent (indeed on any methodology or technology for that matter). The lit- 
tle evidence that does exist provides no real support for their effectiveness. Cerveny and 
Joseph [Cerv88], for instance, found that structured methods enjoined more not less 
maintenance effort than an ad hoc approach. Banker, Datar and Kemerer [Bank91] also 
found a similar result in their survey. A recent case study by Dekleva [Dekl92] showed 
no direct effects on maintenance, although there was some subtle evidence that struc- 
tured methods did facilitate the addition of new functions to existing systems. Wastell 
and Sewards [Wast95b] have reported that organisations using standard methodologies 
achieve lower levels of project success than those using ad hoc or “home-grown” meth- 
ods. 

The evidence that we have discussed in this chapter casts further doubt on the notion 
that engineering rigour is the key to quality. The experience of Acme, for instance, pro- 
vides a salutary “cautionary tale” that having an explicit process model embodied in a 
methodology is certainly not a guarantee of success. Indeed, the case shows that there 
are serious dangers in being too prescriptive about “process”. The new system in Acme 
was a failure and much of the blame was attributable to the methodology which had 
encouraged a blind, uncritical approach to development. The Columbine case also dem- 
onstrates that although explicit procedures (i.e. process models) are central to quality, 
care must be taken that these procedures are not too detailed and prescriptive. 

In a similar vein, Waterson et al.’s study shows that CASE tools, by attempting to 
enforce a “process model”, can severely disrupt the flow of work [Wate95]. [Lequ88] 
has also described the failure of a PSEE project because it conflicted with the individ- 
ualistic way that programmers had been used to working. Visser has shown that 
although design work is notionally guided by plans, the work itself is “opportunisti- 
cally” organised; plan deviations, rescheduling and interpolations are the norm 
[Viss90]. He comments that “a system which supposes- and therefore imposes- a struc- 
tured process will at the very least constrain the designer and even handicap him”. Hoc 
has shown empirically that programming environments can, by imposing rigid struc- 
tures, reduce performance [Hoc88]. The fiasco in Orchid Systems illustrates the dan- 
gers in taking the enactment approach to the extreme. Here the mechanical metaphor 
dominated; processes were seen as formally expressible sequences of routine, recurrent 
activities that take inputs and produce outputs in a largely mechanical way. This simple, 
deterministic view of processes implies that they represent “pre-existing specifications 
of the courses of action that people are supposed to engage in by using them” [Such83]. 
This suggests workers follow procedures akin to the way a computer executes a formal 
algorithm. 
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The study in Orchid acutely shows up the naivete of this view and confirms the find- 
ings of other ethnographic studies in revealing that even routine work, which appears 
on the surface to be mundane and procedural, involves a considerable amount of extem- 
porisation and problem-solving which is rendered invisible in formal process models. 
This hidden work has been referred to as articulation. Gasser [Gass86] has commented 
that: “Standardised representations of office work and it's products, as captured in 
forms, diagrams... are the result of articulation, the local adjustments that make the work 
possible in practice. When the articulation of the work is deleted in representations of 
that work, the resulting task descriptions can only be uneasily superimposed on the flow 
of work.” Similarly Curtis et al. have argued that many of the critical activities which 
bear on project success are poorly described in software process models which typically 
“abstract away” from such “detail”. As a consequence such models “do not provide 
enough insight into actual developmental practices to guide research on software devel- 
opment technologies” [Curt88]. 

Thus the assumption that increased formality is the key to quality appears to be highly 
problematic. Whilst greater rigour may be of benefit, there are clear dangers in “being 
too prescriptive”: rather than improving productivity, the process enactment approach 
may produce the opposite effect. In general, we should beware of treating process mod- 
els as “specifications for action”, as literal descriptions of what people really do which 
can be unproblematically enacted by a PSEE. Instead it would seem better to regard for- 
mal processes as “resources” [Wast94]; they are not followed mechanically, but are 
interpreted, applied with discretion and in practice often circumvented. 



7.5.4 The Software Process is a Learning Process 

A recurring theme throughout our discussion is the clash between two opposing para- 
digms underlying the process approach, the paradigm of control and the paradigm of 
learning. Process support systems, for instance, can be seen as “technologies of con- 
trol”; alternatively, we may see them as “technologies of learning”. The construction of 
process models could be motivated by a desire to control the process (knowing what 
should happen allows the process to be controlled) or the motive could be learning; 
modelling gives insight and understanding, and thereby allows performance to be 
improved. The following quote from Dowson et al. [Dows91] exemplifies the “discipli- 
nary” attitude. “Rigorous, unambiguous process specification allows all parties to 
understand what is supposed to happen. Still better would be support for ensuring what 
is supposed to happen really does happen”. 

In contrast to this hard-line position, our advocacy has been in support of the learning 
paradigm. Land [Land86] has argued that the vast majority of non-trivial software prod- 
ucts are, using Lehman’s terminology, P or E style programs [Lehm91]; they cannot be 
fully specified in advance and their development involves a significant and continuing 
degree of interaction between the software engineering and the application 
domains.The key to software quality thus lies in the existence of effective mechanisms 
that enable learning to take place, not through more rigorous control of the development 
process. Curtis et al.’s field study [Curt88] indicates that cognitive limitations are a 
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major cause of trouble in software development; other field studies have shown up the 
crucial but often ineffective nature of learning processes [Walz93, Wate95]. Tully 
[Tull95] has argued that the “process enactment” paradigm is redolent of Taylorism and 
that “organizational learning” [Seng90] ought instead to he our guiding paradigm. The 
Software Engineering Institute’s process maturity framework basically embodies this 
same philosophy [Hump88]; implicitly, the whole thrust of the framework can be seen 
as directed at improving software quality by establishing effective mechanisms for 
learning - the existence of explicit processes is at the heart of this. We may argue that 
an explicit process model constitutes a kind of “collective memory”; it provides a 
shared conceptual framework and a common language enabling experience to be sys- 
temically accrued and disseminated. Without this memory, learning is impossible. 

The issue of change provides a good illustration of the difference between the control 
and learning perspectives. The inevitability of change is acknowledged, of course, in 
the control paradigm but it is seen primarily as a nuisance, a source of inconsistency 
between the enactment and the performance domains. Change, though, from a learning 
perspective is the critical dynamic. From this perspective, the primary rationale of the 
process approach is to enable change and learning by stimulating development teams to 
reflect on their “processes” in order to reveal potentialities for process improvement. 
The implementation of the Quality System in Columbine provides a highly instructive 
example of the way in which a process approach was implemented with the idea of 
learning (continuous improvement) rather than control as its guiding ideology. 

Although an explicit process model can promote learning, it is worth re-emphasizing 
that it can also exert a pernicious, anti-learning influence. In Acme the insecurities of 
the designers (and the users) led to the use of the formal process in an ineffective and 
counter-productive way. Wastell has discussed in depth the idea of methodology work- 
ing as a “social defense” [Wast95a]. Far from facilitating the development process, 
methodologies have the potential to be used in a mechanical, fetishistic way that inhibits 
creative thinking. The process can become an end itself; it provides a comforting set of 
organisational rituals whose enactment gives security whilst inhibiting effective 
engagement with reality. The grandiose phantasy of an all-powerful method allows 
practitioners to deny their feelings of impotence in the face of the daunting technical 
and political challenges of systems development. But by withdrawing into this phantasy 
world, the learning processes that are critical to the success of systems development are 
undermined. Wastell and Newman [Wast93b] have argued that the stress of systems 
development can undermine effective learning at the group (e.g. groupthink) and indi- 
vidual level (e.g. cognitive “tunnel vision”). 

The learning paradigm is important as it orients software process research to the 
development of process innovations that promote learning. The importance of user 
involvement in system development is emphasised by the learning paradigm; it is only 
through interaction with users that the necessary learning will occur which ensures that 
the software artifact matches the users’ needs. The need to support user involvement has 
led to a number of significant process innovations of which the Pen&Pad project (see 
Section 7.2) provides a good example. Here traditional approaches were rejected in 
favour of a highly idiosyncratic process model which was designed with user involve- 
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ment and mutual learning as the key objectives. Another example is provided by the 
work of Gronbaek et al. which focuses on the obstacles (e.g. physical remoteness, fixed 
price contracts) to user involvement in a commercial product development context 
[Gron94]. These writers suggest measures, such as “process contracts”, to overcome 
these obstacles. The USTM {User Skills Task Match) method offers another innovatory 
process model for dealing with user involvement in a product development context 
[Fowl88] and there are other examples [Kyng93]. 

Others have written stressing learning as the key to software improvement. Salaway 
et al. [Sala87] have argued that the software process should be seen as an organisational 
learning process. They provide compelling empirical evidence that much of the ineffec- 
tiveness of systems projects can be traced back to poor analyst-user communication and 
the dominance of what they call, drawing on the work of Chris Argyris [Argy90], the 
Model I problem-solving style (achieving goals, a win/lose competitive orientation, 
defensiveness). Training measures to promote the Model II learning style (an open and 
self-critical attitude, an emphasis on valid information and informed choice) were 
shown to improve the quality of user-analyst communication. Hutchins et al. have 
described an approach to software process improvement based on applied team-based 
learning [Hutc93]; tangible and lasting benefits are claimed for this approach. Hyman, 
drawing on the work of Constantine, advocates new forms of team organisation that 
stimulate learning and creativity [Hyma93]. In the present context, we should take par- 
ticular note of Hyman’s comment that “elaborate, formal, rule-based methodologies 
achieve consistency through mediocrity... we strived instead to achieve consistency not 
through strict rules but through general principles that take into account context, intent 
and experience”. 

Some writers have advocated the use of specific techniques for enhancing learning, 
such as soft systems methodology [Wast94, WH85] and strategic assumption surfacing 
[Walz93]. In a provocative recent paper, Hirschheim and Klein [Hirs94] contend that 
conventional “process models” (such as structured design) reflect a “functionalist” par- 
adigm, which stresses efficiency and control. They argue that such methods are inher- 
ently conservative. Hirschheim and Klein advocate an alternative paradigm for system 
development (the “neo-humanist” paradigm) which takes as its main theme the poten- 
tial of systems development to bring about radical learning and to achieve human eman- 
cipation. Hirschheim and Klein champion methodologies such Mumford’s ETHICS 
[Mumf83] which embody their neo-humanist aspirations and which enable radical 
learning to take place by giving users the lead role in the development process. 



7.6 Conclusion 

The software process is a complex process. It is complex technically in that software 
systems are sophisticated entities whose design involves the solution of demanding 
technical problems. Software development is complex socially in that many individuals 
are involved in a wide range of roles and activities. Viewing software development as 
a social process brings out its hierarchical, systemic quality. Several different levels of 
analysis are appropriate: the individual, the team, the project and the organisation as a 



7.6 Conclusion 197 



whole. Issues for PSEE design emerge at each of these levels. At the individual level, 
we have been preoccupied with the control dilemma, i.e. the need to impose the right 
degree of prescriptive structure on software work. Process models are normative ideals; 
it is important that their enaction should guide and support the creative human labour 
of software work, not dictate and determine it except in extreme circumstances. This 
means that PSEEs must tolerate deviations from the process blueprint and allow for 
local customisation of processes and workspaces. 

At the team and project level, we have argued that main role of PSEEs to date has 
been a coordinative one, to help orchestrate the multifarious activities that are entailed 
in software work. Following others, we have advocated more cross-fertilisation with the 
field of CSCW which has generated a range of innovative tools to support other aspects 
of cooperation (communication and collaborative problem-solving). The potential of 
the process approach for supporting team learning has been emphasised, although we 
have also pointed out the risk of processes degenerating into bureaucratic rituals. 

At the organisational level, the following chapter reminds us that the software process 
is a production system regulated by a management system. Changes to the software 
process will only bear long-term fruit if they are mirrored by changes in the manage- 
ment environment designed to reinforce those new practices. This is well illustrated in 
Columbine study which shows that managerial commitment is paramount in bringing 
about effective changes in working practices; tools and methods may assist but a clear 
management lead, supported through sustained reinforcement (e.g. the on-going quality 
initiatives in Columbine), is essential if the necessary changes in behaviour and culture 
are to be realised in practice and become a permanent feature. Studies of MIS failure 
also stress that the wider organisational context limits what can be achieved through 
technical change [LyytSS, Mark83]. 

We commented at the start of the chapter that software process research, by empha- 
sizing abstract models of the software process, tends to paint an impersonal view of 
software development in which the role of “people factors” is downplayed. This mar- 
ginalisation of people is potentially dangerous. Software development depends criti- 
cally on human creativity and talent. [BoehSl] has reported, for instance, that people 
factors have an influence on productivity six times greater than the use of software 
tools. [Broo87] argues that methodology alone (i.e. process models) will not “inspire 
the drudge”. Fitzgerald, using an apt analogy, comments that “no one believes that 
merely having access to the same cookbook would cause all chefs to be equally profi- 
cient” [Fitz94]. 

If the quality of software development is to be improved, then a coherent model of 
the software process is required that does full justice to both the technical and the social 
dimensions of the process. A complementary emphasis on people and process is 
required. Recognition of this lies behind the SETs current work on the People Capabil- 
ity Maturity Model which puts forward a structured set of measures for developing the 
skills and talents of software developers within the SETs well-known process maturity 
framework [Curt95]. Without a broad approach that embraces process, people and tech- 
nology, the danger is that any attempt to “improve the process” will founder. Concen- 
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trating exclusively on the technical dimension may lead to technical innovations which 
are doomed to fail because the social dimension has not been adequately considered. As 
long ago as 1986, Land presciently argued that the concept of the “software factory” 
was fatally flawed as it failed to address the social dimension of the software process 
[Land86]; he contended that factory-based methods reduce job satisfaction and rigidify 
roles. Software development requires high motivation, team work and flexibility. Land 
predicted that the likely effect of process support environments would be to increase the 
gap between the best and the worst, not to bring low-performing organisations up to the 
standard of the best. Giving complex tools to untalented people will simply make them 
worse. Due attention to the human dimension of software work is thus paramount. 

Sociotechnical theory provides a general theoretical framework which incorporates 
both the social and the technical dimensions [Wast94]. It is worthwhile as a way of 
rounding off the chapter to look briefly at this perspective. In essence, sociotechnical 
theory conceptualises organisations as open systems (i.e. as intelligent entities that 
interact with and adapt to changing environments) composed of technical and social 
“subsystems”. The technical subsystem of an organisation refers to tasks, processes and 
technologies; the social subsystem denotes the people who work for the company, their 
“psychological need” for fulfilling and satisfying work, and the way that they are organ- 
ised (e.g. as autonomous groups or in line management structures). 

Improving performance from a sociotechnical viewpoint depends on two key pre- 
cepts; joint optimisation and minimum critical specification. Joint optimisation refers 
to the need to pay equal attention to technical and social system design when redesign- 
ing processes. Technical improvements can have social costs (e.g. process automation 
which restricts individual autonomy, CASE tools which rigidify roles) such that overall 
performance is worsened rather than improved. It is vital that both technical and social 
dimensions of the workplace are redesigned together, with the aim of improving per- 
formance through increased efficiency and by creating social conditions which 
strengthen autonomy and motivation. The principle of “minimum critical specification” 
enjoins that the design of sociotechnical systems should confine itself to specifying only 
those details that absolutely must be designed in advance and over-specification should 
be avoid at all costs. This principles follows from the “open systems” view of organi- 
sations. Because change and the unexpected are inevitable, it is important to give indi- 
viduals the broadest possible latitude to cope with new eventualities and to learn from 
experience. 

Calvin Pava [Pava83] presents an illuminating analysis of the software process from 
a sociotechnical perspective. He characterises software work by three main defining 
features; the presence of multiple concurrent “transformation processes”, non-deter- 
minism of workflow, and a high degree of individual autonomy. In essence, Pava sees 
software work as consisting of multiple, overlapping deliberations carried on by flexi- 
ble and fluid networks of individuals (discretionary coalitions). Deliberations are 
defined as “reflective and communicative behaviours concerning a particular topic”; 
deliberations in software work might include; “requirements capture”, “system specifi- 
cation”. The key to improving performance, as we have said, is to optimise the joint 
design of the technical subsystem (deliberations) and the social subsystem (the role net- 
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works). Pava suggests human resource measures to support the formation of effective 
coalitions (e.g. job rotation, team-based pay schemes) and technical innovations to 
assist the principal deliberations (e.g. computer conferencing to facilitate information 
flows, code inspections etc.). 

We have said that to achieve reliable and durable gains in software quality, both the 
social and the technical dimensions of the software process must be given equal weight 
within a unified conceptual framework. Sociotechnical theory provides such a frame- 
work which appears to have considerable promise. It indicates limits, for instance, on 
the enactment paradigm and highlights design criteria (e.g. minimum critical specifica- 
tion) which we have seen are highly relevant to the design of process support systems. 
More generally, it provides a theoretical framework in which a broad debate about the 
design of process support systems can be conducted which addresses both technical and 
social concerns. 
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8.1 Introduction 

Software process technology is an emerging technology that is now reaching a reason- 
able degree of maturity. Although there remains some way to go before it achieves full 
maturity and general use, its potential for delivering products in an industrial context is 
already evident from the work presented here and in the preceding volume [Fink94]. 
The technology aims at supporting the software production process, by providing the 
means to model, measure, analyse and (where justified) to automate software produc- 
tion activities. We believe that it represents a key strategic technology for addressing 
the endemic problems of software process that were alluded to in the opening chapters, 
i.e. to deliver significant improvements in the productivity of the software development 
and in the quality of software products. 

In the hook, we have introduced the essential concepts of process modelling that 
underpin the technology, and we have discussed a range of fundamental issues relating 
to the technology itself. In this chapter, we summarise the main themes and key issues 
that have emerged chapter by chapter. We will then go on to consider the general valid- 
ity of the paradigm in domains other than the software process, as it is our firm conten- 
tion that process technology has general applicability across all business areas, i.e. the 
is no need to restrict its application to that of software development. Finally, there will 
be a discussion of the key influences that are likely to bear on the future evolution of 
the technology. 

8.2 Summary of Key Issues 

In this section, we will summarise the key issues emerging in the various chapters spe- 
cifically devoted to process modelling and technology (i.e. Chapters 3 to 7). Chapters 1 
and 2 present mostly introductory material providing motivation and background for 
the subsequent chapters. 
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8.2.1 Process Modelling Languages 



The process modelling language (PML) is a key concept needed to describe, to manip- 
ulate and to enact models of processes that occur in a complex organisations. Chapter 
3 sets out to establish a set of requirements which a prospective PML ought to address. 

The authors refine the concepts outlined in Chapter 1 to provide a complete set of 
process elements which must be addressed by a PML. In so doing, they seek to widen 
the scope of application of the language: not only do they see the need to describe and 
enact models of production processes, but they recognise that control processes are also 
important and they address the extent to which a PML might address the different 
phases of the software development meta-process. The concept of process elements 
form a key component of the requirements for a PML. The results are presented in tab- 
ular form. The scope of the stated requirements is shown by mapping them to the dif- 
ferent phases of the meta-process, and indicating whether the requirement supports or 
hinders the activity of that phase. 

The definition which has been adopted of a PML allows for the inclusion in the chap- 
ter of technologies a wide field of tools not normally seen as involving PMLs, for exam- 
ple the Microsoft Project tool. The extent to which they can be considered to be PMLs 
is evidenced by mapping them to the different process elements and indicating the 
degree to which they support the various elements. 

The authors provide a brief but comprehensive survey of European PMLs (with some 
US exemplars shown for reference) which will enable workers to appreciate the scope 
and diversity which currently exists in the field with, as yet, no clear preferred language 
emerging. The extent to which they support the requirements is shown by the mapping 
of technologies to both meta-process phases and process elements. 

The authors discuss the issues around whether there ought to be some single all- 
encompassing PML, or whether we have to accept different PMLs for different aspects 
of the modelling activity. The authors recognise that the likelihood of a single PML 
being appropriate for all aspects of modelling activity and enaction is small, and offer 
the conclusion that the latter approach is the only way forward. This approach, together 
with more active re-use of existing technologies, adoption of standards, and facilitation 
of interoperability will enable integration of technologies around the concept of user- 
level evolution of the process model. This may be the catalyst that is needed in order to 
hasten the adoption of process modelling languages into mainstream software develop- 
ment. 

8.2.2 The Meta-Process 

Chapter 4 provides a thorough discourse on the concept of meta-process, leading from 
abstract notions of problem-solving processes to a case study of implementation. Ref- 
erence is made to established meta-process models to provide a theoretical background 
for an analysis of these different models and a comparison of their utility. Significant 
attention is given to the idea that changes to a software development process can be 
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required for a multiplicity of reasons and that these changes can he required at any stage 
of the process. The authors highlight the utility of the modelling and implementing con- 
trol processes alongside the modelling and implementation of operational processes. 
They propose that meta process models be used to facilitate on going learning in soft- 
ware development projects and further emphasise that this learning may need to be 
facilitated within as well as between projects. 

The chapter sets out the rationale for concepts of meta-process and generic properties 
of a meta-process model. These generic properties are method specialisation, task 
decomposition and consistency management. They are integrated so as to form the basis 
of a problem solving process in the Promoter Reference Model (PRM). The structure of 
the PRM process is given by the identification of four behavioural components, viz; 

• Task Analysis which encapsulates the behaviour associated with the defining of 

objectives for a particular task. 

• Technology Provision which encapsulates the behaviour associated with providing a 

model of the method by which the objectives of the task might be achieved. 

• Realisation which encapsulates the behaviour associated with adapting the model of 

the method to the particular organisational context. 

• Enactment which encapsulates the behaviour carried out in the organisational context 

where the model of the method has been realised. It is thus behaviour that takes place 
in conjunction to this model. 

Having given a detailed exposition of the structure of the PRM, the chapter scrutinises 
it in three ways. First, it is compared with a set of requirements for meta-process models 
which the authors identify as being of relevance. Secondly, it explores the relationship 
between the PRM and other better-known models. The models considered are the Qual- 
ity Improvement Paradigm (QIP), PRISM and the Capability Maturity Model (CMM). 
Thirdly, specific attention is given to the requirement that the PRM be implementable. 
A case study of using the PRM to control the execution of a CMM process is given, 
using an implementation in the ProcessWise Integrator system. 

The chapter suggests a number of important directions for future research: 

• Real world validation of the concepts through utilisation in real world software devel- 

opment projects. 

• Longitudinal study to describe changes to a real software development process 

through PRM. 

• Critical analysis of the properties of different meta-process models. 

• Comparison of the utility of different strategies to software evolution such as meta- 
process and configuration management 

8.2.3 PSEE Architecture 

The issue of architecture is of primary importance in the delivery of effective technol- 
ogies to support process modelling and process enaction. Chapter 5 offers the reader an 
architecture that has been developed over a number of years and which gives an insight 
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into the issues that have to be faced and compromises that must be made in the light of 
present-day knowledge. A reference model is described, founded on the basic services 
that must be provided in a system supporting modelling and enaction of organisation 
processes: 

• Dialogue management (the user - system interaction), 

• Process (co-ordinating activities), 

• Workspace (information abstraction), 

• Repository (of process and product data), 

• Communications and Tools. 

These services are mapped to architectural components and described in abstract 
terms, however this is supported by a description of an instantiation of this architecture 
in the Merlin PSEE. 

A particular issue addressed is that of distributed PSEEs. “Determinant requirements” 
are provided and they are mapped to the distribution of process management, the organ- 
isation of the supported process, and the distribution of repository. This is used to con- 
struct architectural alternatives whose advantages and disadvantages are discussed. 

The chapter concludes with a reasoned description of an instance of the reference 
architecture: the Merlin PSEE. 

8.2.4 Cooperation Control 

This chapter discusses various approaches to supporting cooperative processes with 
PSEEs. Such support is crucial for effective PSEEs and has significant impact on their 
architecture. A simple example is used to illustrate the pervasive nature of cooperative 
work in software engineering. The ideal is an environment which not only provides 
users with the right data and tools at the right time, but also ensures that errors due to 
inconsistent accesses to shared data are avoided. Traditional ACID transactions are not 
appropriate in this context since: 

• The cooperative processes may have a long duration, days, weeks, or even months. 

• There may be a varying number of people involved who need to share intermediate 
results in order to work effectively. 

• The appropriate solution to any conflict on updating shared data cannot always be pre- 

defined. It may depend upon negotiation between the users involved which takes into 
account the context of the conflict. 

PSEEs are not alone in trying to support users involved in long, flexible transactions; 
other areas include CAD/CAM, operating systems, and object-oriented database man- 
agement systems. The authors describe a number of advanced transaction mechanisms 
and compare them from a PSEE viewpoint. One common feature is the organisation of 
transactions into a hierarchy. This provides a structure for understanding what is hap- 
pening, and gives a well defined scope to any failure. A competing pressure is the desire 
for sufficient flexibility to ensure that users can resolve conflicts “on the fly”. As yet. 
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no dominant transaction mechanism for supporting cooperation control in PSEEs has 
emerged. This is illustrated by the four examples featured in the chapter: COO, Merlin, 
ADELE, and SPADE. These environments are compared both through the simple illus- 
trative example and the reference architecture described in Chapter 5. 

Erom the architectural perspective it is clear that cooperation control has a wide 
impact. The cooperation control facilities which can be provided depend upon the gran- 
ularity of addressing, and locking data provided by the repository layer. The notion of 
users’ workspaces and operations to copy, share, or synchronise data between them is 
the most common abstraction over the basic repository facilities. At this level one key 
distinction between environments is whether they adopt an existing commercial repos- 
itory (Merlin and SPADE), or have their own repository which is specialised for a PSEE 
(COO and ADELE). A second key distinguishing feature is whether there is explicit 
generic support for cooperation control. In the example environments, COO provides a 
default protocol for sharing data within its transaction hierarchy, while Merlin allows 
generic cooperation patterns to be specified and reused. The alternative to this approach 
is illustrated by ADELE and SPADE. Here the cooperation control required is just part 
of the process model. Cooperation support is not identified as a distinct architectural 
layer; it is just part of the process model enaction. This offers maximum flexibility, but 
it requires process modellers to be aware of potentially subtle coordination problems to 
avoid any mistakes in their models. In addition, sharing generic cooperation control 
facilities between models is more difficult since the cooperation control will be inter- 
twined with the rest of the model. 

Eor PSEE designers the choice of whether to include explicit generic support for 
cooperation control is a key research issue. A number of other research issues related to 
cooperation control emerge through this chapter: 

• What is the impact of distributed PSEEs where local machine failures, or disconnec- 

tions from the network, may hamper cooperation between users? 

• What is the interplay between long transactions and the support for process change 

facilities evident in meta-process research? 

• To what extent should PSEEs adopt techniques from related domains such as CSCW? 

• How can process modellers reason about the cooperation control provided and vali- 
date it against the cooperation needs of users? 

8.2.5 Social Aspects 

This chapter seeks to “re-humanise” research into the software process. It describes how 
the deliberate selectivity of process models can be used to excise human issues from the 
researcher’s agenda. The authors argue that such human issues, far from being of 
peripheral influence, can actually have a critical bearing on the efficacy of software 
processes. Through a wide ranging review which embraces case studies and literature, 
the authors establish the importance of human issues to software process research and 
then utilise their findings to distil a critique of the prospects of software process support. 
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They conclude by identifying a theoretical basis upon which researchers can seek to 
address human issues alongside the technical. 

The authors construct a platform for the debate by presenting three case studies of 
software development. Each of these has distinct features. The first is concerned with 
the application of a structured method to an in-house software development team. It 
shows how the introduction of a rigorous software model does not guarantee an effec- 
tive software process and can, instead, have deleterious consequences. The second case 
study considers the design and implementation of a quality system in a medium-sized 
systems house. It reveals the contextual nature of the adoption of procedures which are 
designed to enhance quality. The authors report that in the case study it was more 
important to develop a broad set of widely understood and general rules, than it was to 
prescribe in detail how quality might be enhanced. The third case considers a novel 
process developed for product development. It highlights the need for learning in the 
process of software development and provides an example of how user participation in 
the process can facilitate this. 

The chapter then proceeds through two threads. First, it develops an eclectic discourse 
on the social dynamics of the software process. This is done by drawing upon MIS 
research, software psychology and some practical experiences of process modelling and 
enactment. Secondly, it reviews the human role in the software process by developing 
a critical evaluation of the framework of Dowson [Dows94]. By seeking to clarify the 
nature of human agency in the framework, the authors appraise the difficulties of effec- 
tively utilising PSEEs in a context of creative and collaborative human endeavour. 

These two threads then inform a further, more general debate. This draws together the 
implications of the human centred perspective for software process support. A number 
of prominent themes emerge. First, there is a need for an “ecological approach” in soft- 
ware process research. It is argued that researchers should acknowledge the empirical, 
problem solving basis of their domain and to seek to validate their work through the 
application of ideas in real world situations. Secondly, software process research can 
find a range of complementary concerns within CSCW research. The authors argue that 
in developing PSEEs, the researchers have confined themselves to a rather narrow focus 
on group coordination. Other, complementary aspects of group work have been 
addressed within the CSCW research community. Thirdly, the limitations of the process 
enactment paradigm should be recognised. The authors argue that the usefulness of the 
paradigm is challenged by empirical experience of the effects of attempts to impose 
engineering rigour upon software development. Fourthly, the software development 
process is a learning process. This idea, that software process innovation (whether it be 
technological, procedural or social) should seek to facilitate learning amongst software 
developers and users, arises at several points in the chapter. The authors re-emphasise 
that it in turn highlights the value of user centred design strategies in the software proc- 
ess. 

In conclusion, the authors identify sociotechnical theory as providing a basis through 
which software process research can seek to address both the human issues recognised 
in this chapter and the technical issues identified elsewhere in the book. Sociotechnical 




8.3 Wider Applications 207 



theory recognises that successful innovation must seek a synthesis across technical (e.g. 
processes, technologies) and social (i.e. people) sub-systems. A failure to optimise the 
interaction of these sub-systems can result in innovations which are of low value or are 
dysfunctional. 

The chapter suggests a number of important areas for future research. 

• The further maturation of a sociotechnical perspective upon the software process. 

• The analysis of results from the CSCW research community and their application in 

the software process domain. 

• The development of strategies and techniques to facilitate learning amongst the par- 
ticipants in software development. 

• Research of software development practice aiming to highlight common issues and 

to identify hypotheses of ways in which these issues might be addressed. 



8.3 Wider Applications 

In this section we consider the wider potential of software process technology. Our 
contention is that PSEE technology is generic, and has the intrinsic potential to support 
any business process, i.e. the model embodied and enacted by the PSEE could be of any 
business process in any domain. To articulate our case, let us begin by considering the 
nature of the problem presented by the software process. We have argued in Chapter 1 
that although it possesses some distinctive aspects, the software process is typical of any 
manufacturing process. Figure 1.1 in Chapter 1 presents a simple model of software 
development as a manufacturing process. A refinement of this model, which is widely 
used in the field of management information systems [McLe90,Beme91] is shown in 
Figure 8.1. 




Figure 8.1 The management paradigm for an arbitrary organisation. 
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It depicts a generic way of viewing any organisation (be it industrial, governmental 
or non-profit) as a system made up of three components: 

• a production process that generates the primary products of the enterprise: it trans- 
forms incoming raw material (input) together with managerial directives (control) 
into the products to be sold (output); 

• a management sub-system that sets goals and regulates the production sub-system; 

• a feedback system (management information system) which provides information on 

the performance of the production process (and other relevant information), allowing 
the management system to determine whether goals are being realised or if corrective 
action is required. 

Given this general model of organisation, we must now ask to what degree does it fit 
the software domain. Figure 8.2 shows a concrete mapping of the software process into 
the model. The arrowed lines in the diagram typically represent the product flows: e.g. 
the input flow contains the (rough) specifications, the output flow the required software 
system and the control flow consists of the work plan and the additional controls .The 
rest of the figure is largely self-evident. The demonstration of this fit is important as it 
supports our general contention, which may be expressed the assertion that: the soft- 
ware process is a paradigmatic problem within the general world of business proc- 
esses, the solution of which is crucial to solve a variety of related domain problems. 

In more abstract terms, let us consider the parallels further. The concept of a formally 
defined process model is central to our approach and, throughout the book, we have 
made a distinction between three process domains: definition, enactment and perform- 
ance. How do these domains map into the general management paradigm? The domain 
of process definition clearly belongs to the management sub-system. The presence of a 
formal model of the production process in the management system is critical. It is a sim- 
ple axiom of cybernetics that without a model, management of a process is impossible. 
This tenet is fundamental to our approach (as it is to the CMM and the quality manage- 
ment paradigm in general, see Chapter 2). Our work draws attention to two roles for the 
formal model in the management subsystem. First, it provides a blueprint for the pro- 
duction system, indicating how production work is to be organised. Second, it provides 
a interpretative framework enabling the flow of management data (metrics etc.) to be 
understood. As noted in Chapter 7, this feedback operates at two levels. At a basic level, 
it provides information on the state of a process, in particular to help identify opera- 
tional deviations from the model. At a higher level, it provides information on the gen- 
eral adequacy of the model, this being essential to the meta-process whereby learning 
(process improvement) occurs (i.e. model evolution). 

Regarding the other process domains, that of performance clearly belongs to the pro- 
duction sub-system, indeed the two concepts are more or less synonymous. Process 
enactment, on the other hand, provides the interface between management and produc- 
tion; it provides the mechanism (execution of the formal process model) through which 
the management sub-system directly influences how the production work is carried out. 
It is in this area that process technology makes its distinctive contribution, by providing 
a direct link between the management and production subsystems of an organisation. 




8.3 Wider Applications 209 



environment 



client 



software engineering 
society 



software engineering 

management 



standards 



team 

manager 



editor 



mail tool 



1 


' ' 1 


1 board 


task builder H 


L 1 J 



manage- 
I ment 
I infor- 
mation 

. „ ..I system 

information 



T 



data (external) 



project DB 



i- 



(rough) 



specificaticj: 



control 

prodnction process 



planning 

checker 



data (internal) 
“ — ~\ 



mail tool 



designer 



editor 



programmer 



tester 






compiler 



document DB 



reviewer 



workbench 



softwarej 



system 



Figure 8.2 Management paradigm for a general but rather unspecified software 
process. 

Having demonstrated in concrete terms that the software process fits the general man- 
agement paradigm and mapped our key concepts into this generic model, we have 
established that our approach has general applicability beyond the software domain. 
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Two key ideas are central to our work: formal process modelling and process enact- 
ment. Wider contributions in both these areas may be identified. 

Regarding process modelling, our field has much to offer the wider business commu- 
nity by providing a rich array of formalisms for modelling (Chapter 3). The general 
value of these modelling tools has already been attested, in that they have been success- 
ful used by contributors to this book in other business contexts, such as healthcare and 
insurance [Wast94]. Continuing the debate in Chapters 2 and 3, we would remark that 
it is unlikely that a single modelling formalism will ever be sufficient (e.g. to embrace 
both static as well as dynamic aspects of processes). The so-called multiparadigm 
approach [Rumb91, Cana94a] would seem the best way forward; [Groe95] refers to this 
as eclectic modelling. 

Regarding the contribution of enactment, we refer back to the arguments of the open- 
ing chapters that process standardisation and compliance are fundamental to the 
achievement of quality. PSEE is a key technology for realising such standardisation; it 
provides, as argued above, the essential link between the domains of management and 
production. But what is the practical evidence that enactment is a feasible and valid 
approach? Notwithstanding the cautionary experiences related in Chapter 7, there is 
evidence from the various demonstrator systems that have been constructed within the 
PSEE community (in domains as diverse as banking and healthcare) that the enactment 
of process models is a feasible approach which has the potential to improve productivity 
and quality [Fink94]. Appendix C provides a further illustration of the application of the 
process approach to the problem of collaborative writing. It should also be noted that 
the increasingly popular technology of workflow automation embodies essentially a 
model enactment paradigm. The value of workflow for improving organisational per- 
formance now seems to be accepted; this provides further empirical evidence regarding 
the validity of the enactment approach. 



8.4 Future Trends 

This final section will discuss various ways in which we see process technology devel- 
oping in the immediate future in response to various pressures. The discussion will be 
organised around three themes: evolution of the technology due to changes in software 
development practices (market push), possible evolution due to pressures intrinsic to 
the technology itself (technology push), and evolution in response to the broadening of 
its perceived application domain (market evolution). 



8.4.1 Evolution of Software Development Practice 

The process technology developed so far (and described in this book) is mainly oriented 
towards supporting limited groups of closely cooperating agents. Typically, it is seen as 
supporting an engineering group working on a specific software product. However, 
most current software projects are carried out by groups of cooperating agents, where 
each group is dedicated to specific activities across a range of projects or to different 
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parts of the same product. In many cases, these groups are geographically dispersed and 
use different basic technologies. 

Moreover, major changes in the I.T. domain which will reinforce these changes in the 
practice of software development. The introduction of cheap and fast network technol- 
ogy, new languages such as Java and Telescript, real interoperability between object 
supports (Corba, OLE etc.) will bring about radical changes in the I.T. workplace. Soft- 
ware work will become progressively more spread out geographically, with developers 
working from home, indeed from any location. Seldom will there be face to face con- 
tact. With teams scattered across the globe, communication and coordination will be of 
primary importance. 

In this future scenario, we envisage that different process-centered environments will 
become more tightly integrated to support such a dispersed, heterogeneous federation 
of loosely-cooperating processes, or that effective mechanisms for the interoperability 
for the software process environments will be developed. Regarding the former option, 
several kinds of federation can be envisioned: 

• an explicit model of the federation in each local process model (peer-to-peer integra- 
tion) using specific features at each site, invoked and controlled by each local proc- 
ess-centered environment and used to send/receive messages/requests to/from other 
sites; 

• a federation server that acts as the coordinator of the different local processes (this 

federation server implements and enforces the policy of cooperation in the federa- 
tion, by providing global services and by forcing/invoking operations at the different 
sites); 

• virtual services offered on the net by each site, that can be transparently invoked by 

any process as if they were local features, or with a real federation process that is exe- 
cuted in a distributed way on the different local process-centered environment (it is 
superimposed to the different local processes in a transparent way). 

To support interoperability, on the other hand, standards have to be identified. Java 
and Corba have been cited above, but standards for repositories, tool integration, for the 
user interface, and for other services (see for instance the OMG proposals) have also to 
be considered. It is likely that such standards will start to appear in the next generation 
of products. 



8.4.2 Technology Evolution 

As seen in body of the book, the domain of software process technology is complex and 
varied. Topics and issues include: process modelling, analysis and improvement; meth- 
odologies for process model development; the reuse and customisation of process mod- 
els; process evolution; process automation, monitoring and control; process metrics; the 
architecture of PSEEs; federated PSEEs; integration of existing products/tools; interac- 
tion with telecommunication infrastructure (in particular, the Internet); human factors 
and technology transfer issues; process technology and international standards. 
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Obviously, this is an active and dynamic research field with many varied topics. Par- 
ticular areas where we anticipate progress include: 

1 . Process modelling languages. Here we expect developments mainly in the areas of 
reuse (of commonly occurring fragments using genericity, specialisation and stand- 
ardised libraries) and interoperability (especially in relation to the project and con- 
figuration management tools, and across different underlying platforms); 

2. Meta-process. Despite the existence of research on software evolution, it seems only 
now that the software engineering community is beginning to appreciate the signifi- 
cance and the complexity of the control issues relating to the software process. 
Progress will appear on questions such as: 

• how do process life-cycles converge and differ, for personal processes, small group 

and large projects [Hump90, Hump89]) 

• what are the basic operations supporting these life cycles? 

• what kind of meta-process is needed? 

• how should real-world processes be captured? 

• what means should be used to check and validate process models? 

• what method should be used to refine initial models into enactable ones? 

3. Process evolution support. This issue, which relates to meta-process, languages and 
enactment support, is probably one of the most challenging aspects of the field. Here 
progress should appear in: 

• process description languages supporting the controlled change of processes, even 

during execution; 

• methods for computing the effect of change (impact analysis); 

• methods for ensuring consistency between the changed model and the status quo ante 

(in particular, data produced by the old process must also be accessible by the 
changed process). 

• methods for migrating extant data into a changed process? 

8.4.3 Application Domain Evolution 

As we have contended, it is our strong belief that other types of business processes are 
fundamentally similar to software processes and that process technology therefore has 
general applicability [Snow94, Gruh94]. Reflecting this conviction, it is notable that 
european workshops on software processes have a section on related domains, see 
[Warb94, Scha95]. Others have also referred to the successful application of a software 
process modelling environments to a number of general business situations [e.g. 
Gruh94]. 

The argument has, however, been advanced that software process technology is just 
a derivative of CSCW or groupware, relying on the superficial observation that most 
software processes are computer supported and are performed by a team of closely 
cooperating individuals. These observations do not say anything about the detailed cor- 
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respondences between software process notions and concepts used for studying group- 
ware. It may be contended that the groupware field is not studying the software process 
field with either rigour or care. On the other hand we argue that PSEEs, although still 
being experimental with respect to the modelling of software processes, are being suc- 
cessfully applied to some groupware problems, see e.g. [Lonc94b]. 

We therefore believe that notions and approaches from the field of software process 
modelling have a distinctive and important contribution to make to supporting organi- 
sational processes. As the strategic and wider relevance of PSEE technology becomes 
better known and understood, this will exert pressure on the field to address old con- 
cerns with new vigour as well as opening up entirely new problems. Issues which will 
become increasingly critical include: 

• modelling languages which are directly intuitive to the non-I.T. literature readers and 

writers; 

• tools for visualising and manipulating process models, including facilities for model 

animation and simulation; 

• improved mechanisms for accommodating externals tools such as word-processors, 

databases etc.; 

• improved mechanisms for monitoring the status of executing process models in order 

to generate management information; 

• mechanisms enabling the integration of legacy systems in a PSEE; 

• enhanced user interfaces including Web-based interfaces; 

• tools allowing local process customistion to facilitate individual working practices; 

• solutions to the federation problem; 

• migration strategies from conventional to process-oriented architectures. 

We believe that process technology is a key strategic technology with a wide field of 
application in the modern enterprise. In particular, the capability of a PSEE both to 
accommodate evolutionary change and to drive evolutionary change in the process that 
it supports is of immense significance at a time when the competitive demands on busi- 
nesses for change and improvement are becoming increasingly pressing [Dave93, 
Hamm93]. All too often, conventional I.T. systems, through their inflexibility, have 
obstructed rather enabled the redesign of business processes [Wast94]. As the pace of 
change continues to accelerate and organisations become increasingly dependent on 
software systems, there is an urgent need for a new I.T. paradigm that enables rapid 
redesign and reengineering of processes. We contend that PSEE technology provides 
such a paradigm. Using process technology as the basis of the entire I.T. infrastructure 
of an enterprise (a single PSEE or a federation of PSEEs) is not a futuristic concept. The 
book shows it to be a realisable practical approach which has the potential to yield enor- 
mous benefits in terms of the ability to rapidly redesign the processes of the organisa- 
tion and to accommodate new tools in a seamless way. 




Appendix A 

Lifecycle (Sub) Process Demonstration 
Scenario (ISPW 9^) 



A.l Background 

This scenario is a continuation of the International Software Process Workshops 
tradition of providing a process scenario as an example of life-cycle suh-processes 
for specifications in different formalisms and implementation and demonstration in 
different systems. 



These examples or scenarios, together with specific guidelines, were designed and 
planned with many objectives in mind, including; 

i) to provide canonical examples as vehicles for distinguishing the distinct 
process definition approaches. 

ii) to provide samples of “real life” issues in order to facilitate the explanation 
of demonstrations and to make those demonstrations appli-cable to prospec- 
tive users. 

iii) to bring about specific technical issues to be addressed by different process 
formalisms and systems and as a means to experiment with those issues in 
the various approaches and systems. 



The original example, from ISPW6, appears in the Proceedings of the 1st Interna- 
tional Conference on the Software Process, held in California, in October 1991 
[Dows91]. Extensions to this example have been proposed in ISPW7 and ISPW8. 



A.2 Introduction 



This year’s scenario is a revision of the ISPW6 scenario, to take away some of its rigid- 
ity, to make it more realistic and tailorable, and to add items related to human-computer 
interaction and computer mediated human cooperation. This scenario is flexible, i.e., 
it provides a base scenario which includes named but un-specified procedures and pol- 
icies. Thus, demonstrators can extend the scenario to demonstrate diverse policies 
and models, and the strengths of their systems. 



1. 9th International Software Process Workshop (ISPW9) 

J.C. Demiame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 217-221, 1999. 
© Springer-Verlag Berlin Heidelberg 1999 




218 A Lifecycle (Sub) Process Demonstration Scenario (ISPW 9) 



This scenario focus on: 

• Life-cycle aspect: Problem Reporting and Change Process 

• Theme: Roles of human in the process and automation support for individual/ 
team activities. 

• Objective: Demonstrate process execution and how a process-based SEE helps 
project users in their roles (e.g., project manager, designers, developers, config- 
uration managers) perform their activities and cooperate with each other. 



The base scenario appears below, followed by a set of sub-scenarios with recom- 
mended themes to be demonstrated together with the scenario. These themes either 
refine the base scenario by including specific procedures, or list candidate functional- 
ities to be demonstrated. 



At 1SPW9, there will be a demonstration day preceding the workshop (open only to 
workshop attendees). Demonstrators are requested to enrich the base scenario with 
the sub-scenarios. It has been our experience that the demonstrations provide a good 
source of ideas and concepts to be discussed throughout the workshop. 



A.3 Problem Reporting and Change Process 

• A software project is on-going, with “parts” of the system already designed, 
codified, tested and baselined (i.e., under configuration management control). 

• A problem is reported by a tester on the testing of a piece of the system under 
development. The project’s problem reporting and analysis procedures are then 
followed and a person is assigned the task of the analysis of the problem. 
(Note: these procedures can be formal or informal, depending on the type of 
project. Notification can be effected by mail, by forms, by a tool. The proce- 
dures may include rules or guidelines telling who assigns people resources to 
study which problems and what kind of steps need to be followed.) 

• A developer/analyst analyzes the problem and proposes a solution. After the 

analysis (which can be illustrated via automated process support or assumed 
to have been done manually), the developer identifies that the problem 
affects one software module which has been coded, tested and baselined, and 
possibly also affects some documentation (e.g., design and/or testing docu- 
ments). (Note: the related documentation can be identified explicitly with 

help from the system, or implicitly via existing predefined rules in the sys- 
tem). 
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• After some analysis, it is noted that the module to he fixed is currently being 
(re-)used by two separate users or teams (again how this is accomplished may 
vary, i.e., the system may flag this issue or this fact may be found explicitly 
by inspection by a configuration manager or the developer). Those users are 
notified of the problem and that the module will be changed. 

• The change process starts according to pre-established change procedures 
(which entail assignment of resources, code and/or documentation modifica- 
tion, analysis/testing/review, approval/rejection and new baseline of the mod- 
ule and associated documentation). 

• The module is checked out of the baseline according to the CM procedures for 
change but reuse of the old version continues. 

• The module is changed to fix the problem. (Optionally, the fix could be done 
by two or more separate developers and their cooperation may be illustrated 
via process support). 

• The module is tested (formally or informally). Once the problem is fixed, 
procedures for acceptance/rejection are followed. Once the module is accepted 
(i.e., the change does fix the problem and it does not violate any of the 
requirements), appropriate regression testing on the modules/systems which 
reuse a prior version of this module can be performed. 

• Once all is done, the change process is finalized. 



A.4 Sub-scenarios 



Demonstrations should explicitly include as many of the following sub scenarios as 
possible; 

(1) Specify and demonstrate one or more specific procedures/policies to com- 
plement the scenario (preferably performed with automated process sup- 
port): 

• problem reporting and/or analysis 

• testing procedure/method 

• analysis of a problem using data in system 

• configuration control: retrieval, storage 

• code fix 

• problem approval/rejection 

• resource allocation 




220 A Lifecycle (Sub) Process Demonstration Scenario (ISPW 9) 



(2) User role support (see definition of role below). 

Demonstrate implicit/explicit support for project user roles, (mul- 
tiple)user-to-(multiple)role assignment (static/dynamic), the impact 
of actions of one role upon another (i.e., automated cooperation among 
roles based on process definition), and how roles affect the interaction 
styles and other aspects of the process. 

(3) Individual Support. 

Demonstrate how individuals are guided about what task to do next, how 
users are made aware of the state of the process, or how the system per- 
forms actions as a result of the users’ actions. Demonstrations should 
clearly illustrate how users are aware of the process, how the environ- 
ment and individuals interact, and what variables control the different 
modes of interaction. 

(4) People Coordination. 

Demonstrate coordination of multiple people, including any support for 
resolution and tolerance of inconsistency. In particular, demonstrations 
can illustrate which aspects of these policies, if any, are hard-wired 
into their systems, and which can be altered by the particular model, and 
when the policy selections are made. 

(5) Configuration Management. 

Demonstrate how software and/or documents are controlled for the pur- 
pose of change, and how individuals using a module in their develop- 
ment are made aware of problems and/or changes to that module. 

(6) Project/Central vs individual coordination. 

Demonstrate how the executing process supports both individual and 
project activities, and how the interactions of those activities are sup- 
ported/mediated by the system. 

(7) Process Changes while in execution. 

Dynamically demonstrate changing any of the process definitions sup- 
porting the scenario and points 1-5 above, and the effects of those 
changes. 

Definition of Life-Cycle User Role (adapted from Webster): An expected behavior 
pattern associated with one or more people when executing life- cycle activities (e.g., 
project manager, configuration manager, developer, system analyst). One person 
can play multiple roles in a project. For example, when someone is writing code, s/ 
he is playing the role of developer; when s/he is doing configuration management, 
s/he is playing the role of configuration manager. 
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Annotated Bibliography on PSEE/PML 



B.l PMLs 

B.1.1 Japanese and American PSEEs 

HFSP[Kata89] demonstrates a successful and formal attempt to apply reflection tech- 
niques to process modeling. A set of meta-operations enable inspection and manipula- 
tion of the state of enaction, that is explicitly represented. However, no explicit 
representation, nor manipulation of process models is allowed. 

APS is intended to support iterative system development, but the process model is 
fairly stiff. It is done in LISP, and is being extended for groupware. 

Arcadia with its APPL/A [Suttl95] language extends Ada with persistent relations, 
triggers, predicates, and transaction statements. A process model corresponds to an 
APPL/A program that is statically compiled into an executable program (an enactable 
process model) and then enacted. 

Relations are stored in the underlying storage management, and can be combined with 
with triggers and transactions mechanisms to manage product changes. 

DARWIN[Mins91]is based on laws to regulate how both the product and the model 
itself can operate and evolve. A Law Governed System consists of a set of objects inter- 
acting by messages, where a law both regulates the exchange of messages and how to 
enforce the laws. The law may be tailored for distinct projects, and may be evolved in 
for one project. 

GRAPPLE [Huff88] describes a plan-based assistant that can make task networks 
based on intentional specifications. 

MARVEL [Kais89] specifies a process model by a rule set denoting the activity part, 
a project type set denoting the product part, and tool envelopes denote the tools. All 
these are stored in the Marvel database. Individual activities (rules) are connected by a 
task network, described separately. 

Process evolution is supported in a special language, by imposing a set of constraints 
that define the legal evolution steps. 

A follow-up project called Oz, with emphasis on decentralized process modeling, is 
described in . 

B.1.2 European PSEEs 

J.C. Demiame, B.A. Kaba, and D. Wasted (Eds.): Software Process, LNCS 1500, pp. 223-225, 1999. 
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ADELE [Belk94] s composed of two major components: the ADELE kernel cover- 
ing low level object storage and coordination, and the ADELE-Tempo extension cov- 
ering process management. The latter defines a process model based on role and 
connection. A role allows dynamic redefinition of behavioral properties of the associ- 
ated objects. A connection expresses how processes collaborate. 

ALE [Cana94a] exploits the MASP (Model for Assisted Software Process) model for 
describing generic templates and instantiating them into concrete process models. A 
MASP consists of an ERA object model, an operator model, a rule model, constraints, 
and invariants. 

EPOS [Conr94c] offers a PML, called SPELL, that is an object oriented and reflexive 
language to describe generic, customized, and specific process models[Jacc93] . It is 
not a visual language. Templates are described by object entity and relation types while 
instantiated models are represented by instances (objects and relationships). SPELL is 
executable and offers supports for evolution. 

E3 [Bald94] offers a graphical PML to provide intuitive process model template 
descriptions. The E^ PML is based on an object-oriented data model extended with 
relations. 

MELMAC [Deit90] lets generic process models be expressed as refinable EUN- 
SOET nets. A EUNSOFT net mainly consists of a hierarchical Petri net where each 
transition may be marked with a modification point denoting that the transition may be 
refined before executing it. An instantiated process model is given by a EUNSOFT net 
whose transitions are linked to tools and where an initial marking is defined. 

MERLIN [Scha94] enables a three level description of software process models: the 
project level defines project status by means of predicates; the process level provides 
project independent information, e.g., objects types as well as predicates. Finally, the 
kernel level consists of a set of Prolog-like rules that govern process enaction. 

OIKOS[Monta94]lets process models be described by typed entities, that belong to 
different classes. Each entity is described by an abstract and a concrete view. Mecha- 
nisms for refinement and customization are provided. A graphical notation is provided. 

PADM [Bruy94] is being developed by the Informatics Process Group at Manchester 
University to provide a total methodology for the acquisition, definition and enactment 
of software process models. This is based on both a specification method, called the 
Base Model (BM), and ProcessWise Integrator (PWI) PML. BM provides constructs 
to specify single and composed objects. The PWI-PML encompasses six aspects: con- 
current threads of execution, dynamic thread creation, subtyping, persistence, user 
interface, and application interface. 

PEACE/PDL [Arba94] follows a goal-oriented approach and is based on a non- 
monotonic autoepistemic logic. Each process model fragment is described by a speci- 
fication and an implementation. A specification is given in terms of an object and an 
operator model while an implementation consists of encapsulated operator models, a 
set of rules and a set of event handlers. 
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SOCCA [Enge94] uses object-oriented class diagrams to model the data perspective, 
PARADIGM is an extended version of state transition diagrams and it is used to model 
the behavior perspective, and object flow diagrams to model the process perspective. 

SPADE [Band94] offers a PML, that is called SLANG. SLANG is based on Petrinets 
and it has been extended with modularization, instantiation, and reflexive facilities. 




Appendix C 

Case Study Demonstrating the Wider Applicability 
of the PSEE Paradigm 



Editor: Jean-Claude Derniame 

Contributors: Luuk Groenewegen, Vincenzo Ambriola 



C.l Introduction 

This annex presents a detailed example of process technology usage. It describes the 
collaborative writing of this book and especially this part of it. This example has been 
selected not only because we know it, but also because it seems quite easy to under- 
stand. It is also because it can be seen as an illustration of our fundamental assertion pre- 
sented in Chapter 8 that “software process modelling constitutes a kernel problem 
within the general world of processes, the solution of which is crucial to solve a variety 
of related domain problems”. This example serves also to support a detailed discussion 
and a demonstration of this assertion that can be obtained from Luuk Groenewegen^ 
(LUUK @ ml winw . leidenuniv.nl) . 

The example is first presented informally and then it is modelled twice in terms of the 
basic concepts of software process modelling, firstly following a bottom-up approach, 
close to a scenario description, and the second using a top-down and more generic 
approach. 

So it will be interesting to observe to what extent the concepts from software process 
modelling are suited for modelling it. 

C.2 Informal Formulation of the Example 

During a PROMOTER meeting it was being proposed that the PROMOTER commu- 
nity should start working on a second book. In contrast to the first book [Fink94], con- 
taining a project-oriented presentation of PROMOTER’S software process activities, 
this second book should contain a problem-oriented presentation of the software proc- 
ess modelling field. 

Some preliminary decisions were agreed on such as 

• for every chapter there should be one editor, at least two authors, and two reviewers, 

• the editor will write down a preliminary version of the book writing process model. 



1 . The contribution by Luuk Groenewegen has been partially supported by the Netherlands Organ- 
isation for Scientific Research (NWO). 

J.C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 227-244, 1999. 
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• editors and authors were to be appointed the following day, after the decision about 

the book structure (in chapters) would have been taken. This formed a first set of 

rules to follow, but obviously to enhance and complete. 

The following days were devoted to detailed discussions and it appeared very 
quickly that it would be helpful to model the process and to be driven by this model in 
a group of about 30 authors. Thus this model, indeed even the role assignments, must 
be flexible. 

The organisation and the process have effectively been subject of numerous changes 
along the book writing. For instance, during the long period of elaboration of this book, 
some authors left the group, some chapters have been dropped, some new rules have 
been adopted, etc. Even the set of editors has changed. 

This kind of change in organisation, plan definition or roles assignment, occur also 
very often in software development projects. 

C.3 A Preliminary Discussion of the Example 

To many readers this example might seem rather remote from the software process 
world. As a matter of fact, in the beginning a lot of objections were raised against it, 
but a lot of supporting arguments were also put. For the reader, these objections and 
refutations may be helpful, and we discuss them here beginning with the objections. 

As it is, the example presents a process of writing a book together, i.e. collabora- 
tively. In CSCW there is a certain standard problem for which different strategies have 
been formulated, see [Posn93]. The way we did the writing cannot be considered as a 
fully fledged CSCW example. The tools we used for this writing are just normal email 
tools for the communication, and Framemaker for the text editing. Although Frame- 
maker certainly is advanced document publishing software, it has no groupware fea- 
tures whatever. On the other hand, some of the papers from CSCW [Posn93], do not 
really touch the typical groupware features from tools, such as groupware editors, in 
the approaches they are discussing. So the computer support in the example is on the 
classical level, but the work in the process from the example certainly is cooperative. 
All this results in a specification not less detailed than those from the aforementioned 
CSCW references. 

This collaborative book writing is actually a real world process with the additional 
merit that it can be considered simultaneously from viewpoints outside the software 
process world and from outside the organisational process world. 

But in fact it is not so remote, in fact during the design phase decisions have to be 
discussed and controlled, tasks have to be assigned, followed up, reviews have to be 
organised, and so on. Thus it is close to a management process. 

On the other hand the book-writing process has a lot in common with software proc- 
esses. For instance, the model change issue is of fundamental importance as seen 
above. Moreover the structure of the book changed during its elaboration and variants 
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of the plan appeared as well as versions of chapters and sections, design and writing 
were continuously intertwined, and so on. As a consequence the following process 
model fragments PMl to PM6 could also be considered as illustrating software process 
modelling. 

According to their nature, the objections can be divided into three categories, with 
four objectives in each; 

• the global objections (og-), 

(ogl): The example is too soft. 

(og2): The example is too easy. 

(og3); The example is too remote from software process development. 

(og4): Why this example? (meant as a rhetorical question) 

• the technical objections (ot-), 

(otl): The present technology is missing in this example: no database, no tools 
of a sufficient high level — only simple ones like an editor and email — and 
no user interfaces. 

(ot2); The example is not automated. 

(ot3): The example has no PML formulation, there only is an informal formu- 
lation. 

(ot4); The example has no architecture. 

• the objections having a process character (op-). 

(opl): The example is a process that has taken place just once. 

(op2); The example has no enactment. 

(op3); The example has no reuse. 

(op4); The example has no meta-process. 

The supporting arguments have also been classified according to the same three cat- 
egories: 

• the global supports (sg-), 

(sgl): The example given to a different community, would result in a less pre- 
cise model. 

(sg2): The example gives the opportunity to compare this model with those 
already existing for a similar situation. 

• the technical supports (st-) 

(stl); There is no multi-user editor available for this example, that is suffi- 
ciently well understood and mature for use. 

• the process supports (sp-) 

(spl); The example has an incremental model. 

(sp2): The example has a feedback loop between the process’ performance and 
the model. 
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(sp3): The example has different versions, which at least partly can be reused. 

(sp4): The example has communication with other authors, resulting in 
change. 

(sp5): The example has a meta-process (see model PM7 in Figure C.C.7 on 
page 238). 

(sp6): The formalism used is simple enough to be easily understood, it is 
close to workflow models and it has enactment support. 

Let us now briefly discuss these arguments. 

As a general comment on the global objections, one can say, “wait and see”. But 
some remarks can already be addressed: the strong point in og3 can be an answer to 
og4. We do indeed want to have an example that is from another process world, so the 
farther away from software processes the better. Moreover, it follows from sg2 that a 
similar example exists in a different community, see [Posn93]. So the objections ogl 
and og2 do not apply, they apparently reflect an excessively myopic view of software 
process modelling to the outside world. On the other hand, the support sgl probably is 
somewhat optimistic. 

Of the process objections, only opl is true, but in the light of support spl the process 
of the example is much evolved. Thus there are many versions of the model, each 
reflecting a partial history of the process from its beginning, together with a detailed 
plan for the near future, and a much vaguer plan for the remainder of the process. Some 
parts of the model are being iterated, possibly in an adaptive way. So there is reuse. As 
the model certainly expresses which activity it is important to proceed with, there is 
also enactment. As a part of the process consists of explicitly adapting the process’ 
model for the various evolutionary changes, there clearly is a meta-process. 

C.4 A First Level of Process Modelling 

In this way of using the concepts presented in Figure 1 .4 on page 7, we follow the evo- 
lution of the book writing process as described before. This first model PMl is as 
empty as possible (see Figure C.l), but it has the potential of growing into a model for 
however substantial a process. As we present only completely instantiated models, the 
entity types will be indicated in the lower left corner of each instance, A for Activity, 
I for Item (or product), Ag for agent; T for Tool, P for Performer, R for Role and D for 
direction. 

So the almost-empty model only contains a very simple meta-process-like activity. 
This meta-process activity can create the first more substantial model of the process. 
This model will also contain a meta-process activity, enabling that model to generate 
a subsequent model version too. And so on. 

The next model (see Figure C.2), represents the situation almost immediately after 
the decision was taken to write this book. At that time it was not even clear what the 
topic of the book would be. 



C.4 A First Level of Process Modelling 231 




Figure C.l PMl; the nearly empty process 

In the Figure C.C.2 we have used a comb-like notation to indicate associations. This 
enables us, for example, to draw a one-relation instance “is for” between the two activ- 
ities “write 2nd book” and “discuss plan” and all the performers who are involved, 
instead of drawing these relation instances. 

The next version of the model reflects the results of the first part of the discussion, 
fixing the approach to the second book as being problem-oriented, which is rather dif- 
ferent from the approach in the first book, being project-oriented. So first, in model 
PM2 the item “book plan”, being the result of the discussion, is updated with the “new” 
plan. Then the activity “make next model”, being the local meta-process activity, pro- 
duces the correct instances for the next model PM3, (see Figure C.3). Note that from 
now on we not only leave out the almost-empty process for launching other PRO- 
MOTER activities, but we also drop the part of the process that already took place. The 
reason for that is only one of space. Otherwise our pictures would have become more 
complex, with unfortunate consequences for their readability. 

The next version of the model should reflect the results of the last part of the discus- 
sion on that day. So first, in the next model the item “editing roles”, resulting from the 
activity “discuss roles” where also the item “book plan” has been taken into account, is 
updated with the general roles. In addition some constraints for the separate chapters are 
also fixed. In particular, it is established how the global activity “write 2nd book” is to 
be refined into smaller activities, corresponding to the various roles see Figure C.4. 
Then the activity “make next model”, being the local meta-process activity, produces 
the correct instances for the next model. This last model results in quite a complex fig- 
ure, so one can easily imagine how even more complex models result in really incom- 
prehensible figures. The model needs to be presented in fragments. A notable 
observation is that sequencing of activities is expressed through a requirement in natural 
language. Obviously here any well fitted formalism could be used to describe it - in this 
case “discuss structure after its having been prepared”. One of the languages described 
in Chapter 3 could be used for that. 

As a result of the preparing activity, the model was further updated with a chapter 
stmcture consisting of nine chapters (subsequently amended to eight). Here can be 
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Figure C.2 PM2; Process model for producing a book plan 



observed here the appearance of a second, more local meta-process activity which is 
responsible for generating the correspondingly more local process (fragment) models 
addressing the (re-)organisation of the writing each particular chapter. This actually 
means that the whole model for writing book 2, now contains one meta-process activ- 
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Figure C.3 PM3 process model for assigning global editing roles 

ity for each chapter, and one on the more global level for the book as a whole. Then 
meta-process is also structured. 

This complexity has to be captured by the model. It actually reflects the distribution 
of the responsibilities within the project. Every performer is responsible for some task 
consisting of one or more activities. But some, or even many performers are more 
responsible than others: in order to perform the task they have some freedom — or the 
freedom — to find a way how to perform it. So they are allowed to invent an appropriate 
process. 

In fact it appeared very early on that it would be too difficult to envisage a complex 
process description only at this level. A bottom-up approach is useful in a first stage to 
capture the process and to identify the components but it cannot help enough for more 
complex processes. A second set of models using the metamodelling concepts has then 
to be defined to obtain a clearer description of the process which could be completed, 
refined and transformed until being able to be enacted. 








234 C Case Study Demonstrating the Wider Applicability of the PSEE 




Jean-Claude 
has role of 
general editor 



Alfonso 
has role of 
coeditor 



m 



DO 3 times, 
parallel per chap. 

write chapter 
- review chapter 
write introduction! 
finish coherency 

Ali has role of f’ook 2 is F ed„ >1 authors, 

technical staff problem-oriented 
& support ^ n 



D- 



Figure C.4 PM4; Process model for producing bookstructure alternatives. 
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C.5 A Top-Down LCPS Model for the Example Process 

At the end of the Promoter kick-off meeting, the editor was tasked to produce a prelim- 
inary version of the process model. It was done using the key notions of software proc- 
esses as they appear in Figure 1.4 on page 7 also referred as the LCPS model [Dern94]. 
This model could seem very simple hut due to the semantics attached to each entity type 
and the existence of a definition model as well as an enactment model it is powerful 
enough to represent most of the situations encountered when describing a process fam- 
ily so as to understand it and to enact it. Due to the intuitive aspect of the example proc- 
ess, and to previous experiments, we didn’t need much effort to capture the process, and 
it was possible to draw models in a more top-down fashion. 

In fact, the first model coming to mind is the product model, drawn in Figure C.5. In 
this schema, the types will have to be instantiated; this activity will be part of the role 
“coordinator”. In the LCPS model any entity type inherits from the “object” type and in 
doing so it can have variants and versions which are managed in the repository 
(although it currently misses a transaction mechanism, which could be one of those pre- 
sented in Figure 6.3). Thus the book could have variants and versions as well as its com- 
ponents. In our product model only book and chapters have variants and versions (there 
is a variant change when the structure of the book changes for instance and versions 
only when the contents changes) and sections only have versions. The model fragments 
themselves, being of object type instances also have variants and versions. 




Figure C.5 The preliminary product model 
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Then, the activities needed to huild the model have to he identified.The first result 
looks like Figure C.C.6, in which the product items have not been represented. It can 
he observed that most of the initially identified activities, are relevant to the meta-proc- 
ess level, those that are drawn in grey. Two important remarks can be raised at this 
level; 

• the result of the activity produce general templates, (or process model), which is of 
product type, is part of the process model to be enacted; it is the way adopted in 
LCPS to reach reflexivity: each entity type, being a sub-type of product, can be 
given by an activity, and particularly an activity type can be the result of another 
defining activity. Obviously, the model so modified has to be versionned (i.e. see 
the notion of transient process in [Kaba94]). 

• the global process model probably changes slower than the plan or than the assign- 
ment of agents to roles, and can be considered closer to the process itself than to the 
model. It can be also considered to be in between, as we will do.They are not at the 
same level of abstraction; and this is the reason why this is so, for the same roles 
(for these roles see [Lonc94b]). 



As with PMl, this first model PM6 is as empty as possible, but it has the potential 
of growing into a model for a more substantial process. It also shows three different 
levels of abstraction: the production process, the management process which is rele- 
vant to the coordinator role (and which is a meta-process for the production one) and 
the modeller process which is the uppermost meta-process. 

We can isolate the modeller part of the process and draw it in Figure C.7, and the 
coordinator part in Figure C.8 considering them as views on the model. We can also 
refine the production process in the following figures. 

The production process model itself is versionned (but the modeller process didn’t 
change during all the book writing). 

The preliminary directions are some of those seen as fixed at the beginning and new 
ones: 

• Jean-Claude should be the coordinator. 

• for every chapter there should be one editor, at least two authors, and two reviewers. 

• book 2 is problem oriented. 

• for writing the book the general algorithm will be 

{// modeller process, 
coordinator process 
production process}; 
in which the production process can be characterised by; 

For each chapter in parallel 
DO 3 times, 

write chapter; 

review chapter; discuss chapter; 
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Figure C.6 PM6; The initial global process model 



write introduction; 
review; update; 
edit; 

Rights are introduced in LCPS to capture responsibilities. The process modeller has 
the “definition righf’ on the initial process model, so he can refine or redefine it. Then 
he receives the definition right on the activities he creates as sub-activities of this initial 
process, and so on. He can keep it or give it to another role. For instance, he can give 
the definition right on write a chapter to the coordinator to allow him to create instances 
of this type (and he did). It is obvious than this notion of rights for one activity on 
another can capture organisational features. In addition, in LCPS there is a notion of 
control right which allows an activity to control that the directions of another activity 
(the controlled one) have been fulfilled when this activity would like to stop. 
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Figure C.7 PM7;The preliminary modeller process model 
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Figure C.8 PM8; The preliminary coordinator process 
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This coordinator process started during the PROMOTER meeting in Villard de Lans, 
even if, at that time, it was not even clear what the topic of the hook would he. So the 
first loop in this process consisted in creating new nearly empty processes for writing 
the chapters. This enabled also the coordinator to launch other PROMOTER activities. 

The production process itself can he refined in write an index, which is an instance 
(see Figure C.9), write a chapter (see Figure C.IO), etc. Creating instances, with the 
“definition right”, the coordinator obtains the “control right” on the created activities 
(only the owner of the control right on an activity can decide if this activity is finished 
or not, i.e. if it has reached its objectives, expressed in the directions; so the definition 
right reflects the responsibilities on the modelling activities whereas the control right 
reflects those on enactment). 




Figure C.9 PM9; “Write an index” process 



With the write a chapter process model, the coordinator can create a set of instances 
for the process write this chapter, he can assign the roles and build the preliminary plan, 
and then obtain a process looking like Figure C.l 1. 



C.6 Discussion of the Example Process Models 

In the above example we have actually applied software process modelling to a process 
from a different field, which is CSCW, and it is about how to write a collaborative book 
(see also [Posn93]). In this case the book is not just any book, but a very specific book, 
in fact this one. This should make for a single unambiguous process model. It is quite 
removed from being a generic model, nor even a customised model, but in fact an 
instantiated model. 

What we see, however, is not one process model, but a whole series of them. Moreo- 
ver, on closer inspection of such a model from the series, it seems to be only partially 
instantiated. The remainder is partially customised and even partially generic. 
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Figure C.IO PM 10: “to write a chapter” process model 

We can here reiterate and number the activities to facilitate discussion: 

1 . write 2nd book, 

2. discuss plan, 

3. discuss roles, 

4. prepare structure, 

5. discuss structure, 

6. form small groups, 

7. discuss all groups, 

8. discuss set-up, 

9. prepare sheets, 

10. present sheets, 

11. discuss all sheets, 

12. write chapter XX, 

13. review chapter XX, 

14. write introduction, 

15. put together, 

16. make chapter model, 

17. make book model. 

Activity 1 consists of all other activities, so it globally refers to the model as a whole, 
particularly its activities. At the date of the model the process fragment consisting of 
activities 2 to 1 1 is fully instantiated and even enacting, as all performers know every- 
thing about what to do and when to do it completely in accordance with the model.The 
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Figure C.ll PM6: “To write the chapter XX” process 

process fragment consisting of activities 12 and 13 is only customised. Nevertheless 
exactly how to do the actual writing is still very unclear. In particular it is still unknown 
where and when the writing will start, and who is to write about exactly what. The proc- 
ess fragment consisting of activities 14 and 15 is not more than generic, as it only very 
generally reflects a standard editing task. Even with the (co)editor and technical staff in 
charge, this part of the model has not yet been fully customised. 

Like activity 2 to 11, the process fragment consisting of activity 16 as well as that of 
activity 17 are instantiated and enacting. It is essential for the model to have the possi- 
bility to evolve, and the very activities 16 and 17 are providing this possibility. At this 
point it is interesting to observe how the enactment of the three levels of models (mod- 
eller, coordinator, which are meta-processes and the “write chapters” model at the proc- 
ess level) are tightly intertwined; this is the basic mechanism to support model 
evolution during enactment as seen in Chapter 4, and here to support the model refine- 
ment and its progressive definition. For instance, we can see in Figure C.8 that the plan 
to be used later in the production process is produced by the coordinator. 

Another observation is that sequencing of activities does not explicitly appear in the 
models; for instance requirements such as “discuss plan change before updating it” are 
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supposed to be expressed in the directions. In most of the languages presented in Chap- 
ter 3, these constraints are expressed directly in the language. 

In the second series of models (see Section C.5) we did not continue to follow the 
sequence of activities but rather a top-down and typed approach. Entity types are 
instantiated when needed. Another observation here is the usage in this model of the 
notions of roles and rights to reflect the responsibilities within the project.We have 
seen in Section C.5 that the coordinator receives the definition right on the write a 
chapter activities allowing him to do the roles assignment and to define the plan. In 
fact he could introduce two (or more) levels of detail, keeping for instance the defini- 
tion right on write a chapter, composed of sections and giving the definition right on 
write a section to the chapter editor. Here in fact this definition right on each chapter 
has been given to the chapter editor as it can be seen in Figure C.IO (this right is 
defined with the “elastic band” policy: the giver keeps the ability to take back the rights 
he gave). The model fragmentation, the separation of roles and the notion of rights 
allow this flexibility. This actually means that the meta-process is refined into frag- 
ments which are distributed to the different actors to dynamically reflect the responsi- 
bilities. That is a true management issue: this reflects the delegation and the control of 
responsibilities. 

Moreover, in order to be able to customise, instantiate and enact new process model 
fragments on the fly, and even in parallel, the right and the responsibility to change 
such a fragment is distributed over these fragments, in particular over performers 
active within their fragments. These performers collect information concerning the 
already enacting part of that fragment. This exactly provides the feedback for changing 
that fragment on the fly. Such a change then will include further customisation, instan- 
tiation and enactment of the relevant parts of that fragment. 

As a consequence, in order to perform the task the performers can have some free- 
dom — or the freedom — to find a way to go about its performance. So they are 
allowed to invent the appropriate process, that is fundamental to human activity. And 
it can be captured by the model. 

Even a global organisation change can be carried out. For instance, for the book 
itself, the set of editors had to be reorganised, with Jean Claude, Brian, David and Ali 
forming the final board. 

As a third observation we offer a brief evaluation of the various objections and sup- 
ports from Section C.3 (A Preliminary Discussion of the Example on page 228). We 
refer to the numbering as introduced there. 

The global objections were denoted as ogl — og4. Although the example is certainly 
not a software process, it is neither soft nor easy. Especially with respect to the obser- 
vations above, these observations are also very valuable for software process models. 

The technical objections otl — ot4. They are simply not objections, but in fact 
advantages leading to the important observations discussed above. Moreover, regard- 
ing og3: that there is no PML formulation for the example, is clearly untrue. The two 
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kinds of models represent a whole series of these formulations. That we have chosen 
only a very general PML with no primitives whatsoever for expressing behaviour or 
communication, is only because we wanted to avoid those details for this discussion. 
Class room experience however shows that more advanced PMLs can also be used. 

The last class of objections were those with a process character opl — op4. As 
already stated in Section C.3 it indeed follows from the example that op2 — op4 are 
completely untrue. The example has enactment, even in a “gradual” form, as it follows 
from the first observation above. The example certainly has a meta-process, as meta- 
process activities are distributed over the model as responsibilities for certain perform- 
ers in (disjoint) process fragments. Reuse of process fragments occurs quite frequently 
as the change mainly consists of refinement of not-yet-instantiated process fragments, 
maintaining, i.e. reusing, those already instantiated. 

As for the various supports, the two general ones sgl and sg2 are clearly related. 
Comparing the above models with the writing together example in [Posn93], we see 
more detail in our models, and we see evolution and meta-process features. In that 
respect our model is much more precise. Also the alternation between full meeting dis- 
cussions and private or small group preparations displays a greater abundance of detail. 

Of the technical supports, especially stl seems rather questionable. Automation of the 
model seems feasible with respect to a whole range of PMLs, even that type of meta- 
process giving a process engineer — through the model — the explicit task to design 
and enact the next model version. Only one drawback remains. The real life changes are 
much quicker than such a process engineer could possibly model them. So real enact- 
ment probably is still beyond our reach. 

The remaining process supports spl — sp5 are more or less self-evident after the 
example. 



C.7 Conclusion 

In this annex we have been able to show that a general organisational process can be 
modelled in a simple PML. As this PML is very general, lacking specific language con- 
stmcts for direct modelling of various kinds of process elements, this means that other 
PMLs are also suited for modelling general organisational processes. So we can be con- 
vinced that software process modelling approaches are indeed applicable to the world 
of general organisational processes. 

To do that we studied a well known example from the CSCW world, “writing 
together”. In our case this example was customised and instantiated for the writing of 
this book. We came to the conclusion that performers often needed to change their 
model. This is in complete accordance with the findings in Chapter 4 and 7. In Chapter 
7 it has been argued that enacting process models should give sufficient freedom to the 
human performers involved in the corresponding real process. In Chapter 4 it has been 
argued that every organisational (sub)activity ought at least to consist of a component 
capable of redefining this (sub)activity. 
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The other interesting phenomenon we want to underline, is the occurrence of a cer- 
tain pattern in the ordering of the various activities, and correspondingly in the com- 
munication these activities bring about. Referring to the activities as they have been 
numbered in the previous Section C.6, we have observed the following. In relation to 
the various meetings in the example, several overlapping groups of activities display a 
certain similarity. These groups are; activities 2, 3, 4 and 5, activities 5, 6 and 7, and 
finally activities 7, 8, 9, 10 and 11. The similarity of these groups of activities consists 
of their global dynamic pattern, being firstly having a discussion where all members 
are involved, secondly having preparations on an individual basis or in small groups 
in view of the next full meeting, and thirdly again having a discussion where all mem- 
bers are involved. This is different from the patterns discussed in [Lonc94b], which all 
take place within the same meeting. 

In the particular case of the third group of activities we even see a refinement or spe- 
cialisation of this pattern. Activities 8 and 9 together, discussing a possible set-up of 
the chapter to write, and preparing some sheets for the next meeting, containing the 
proposal for the chapter plan, constitute the preparations undertaken in a small group. 
Activities 10 and 1 1 together, presenting these sheets and discussing all the presented 
proposals, constitute the final discussion where all members are involved. 
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Editor; Pierre- Yves Cunin 

Contributors: Ilham Alloui, Selma Arbaoui, Denis Avrilionis, Christer Femstrom, 
Samir Dami, Jacky Estublier, Flavio Oquendo 

Motivation and Objectives 

Any attempt to compare Process-sensitive SEEs often results in a poor coarse-grained 
and non-objective classification. Trying to grade whether or not and how a system sup- 
ports a concept or a paradigm is not an errorless exercise. 

Our objective is twofold; 

1. Obviously no system is currently better than any other for all of the process aspects. 
Depending on the approach and on the research focus, any system has strengths and 
weaknesses. We consider that assessment against a framework is much more mean- 
ingful than mutual comparison. In order to be fair, such an assessment has not to be 
done by our group. Instead: 

a) A PSEE designer may do that for his/her own environment. He/she will obtain a 
consistent and complete picture of his/her system, highlighting the weaknesses, 
the strengths and the characteristics. This framework may help people get a syn- 
thesised view of the current status of their system. 

b) A potential user (or group of users) having process support requirements may 
apply this framework to assess various available PSEEs to help decide which one 
will better satisfy his/her needs. 

2. As various people may potentially assess their systems it is important to try to keep 
them within a common universe of discourse. One way to do that is to give extensive 
explanations on each of the topics. We decided that a good illustration through small 
specific examples, which could also be considered as exercises, was a better way to 
reach a high level of clarity and precision even if, by doing so, the semantics of the 
topics would be more suggested than formally or informally described. 

This document does not define the semantics of the concepts used except when nec- 
essary. Other publications have already given very useful taxonomy and concepts def- 
inition. The glossary within this document defines most of these concepts. This 
document should not be considered as an alternative to them but as a step forward 
towards a better understanding of PSEE underlying concepts, and thus a fairer assess- 
ment relying heavily on these basic and fundamental pieces of work. 

J.C. Derniame, B.A. Kaba, and D. Wastell (Eds.): Software Process, LNCS 1500, pp. 245-276, 1999. 

© Springer-Verlag Berlin Heidelberg 1999 




246 D Assessment Framework for PSEEs 

Content of the Document 

The document is subdivided in seven sections. The first two are dedicated to the two 
most well known process elements, i.e. product and activity. These concepts are not 
described in full details. The objective of these sections is to analyse them from a rather 
global and distant point of view knowing that many refinements will be developed in 
the five remaining sections. 

We have grouped the items under the following headings: 

• Product 

• Activity 

• Workspace 

• Cooperation 

• Process and Meta-process 

• Process Tracking and Time Constraints 

• Human and social aspects, Costs and Benefits 

The assessment framework consists in a structured set of concerns and for each of 
them differnt alternative ways to implement it. When possible the assessment with 
respect to a concept is presented in an incremental way going from low level up to high 
level of support. 

The document contains many small examples,they are written in italics. Each of 
them is intended to provide clarification about a certain concept and to help the user to 
decide whether or not the PSEE he/she is assessing supports this concept. 

D.l Product 

Two aspects have to be modelled: one dealing with the support available for describing 
the software artifacts (e.g. source files, documents) upon which the process is going to 
operate (i.e. a Data Description Language, or DDL), and the other dealing with the 
operators available for handling those artifacts during process execution (i.e. a Data 
Manipulation Language, or DML). 

We shall use ‘Object’ as generic term to designate any arbitrary software artifact. 

D.1.1 DDL (Data Description Language) 

D.l. 1.1 Description of object Characteristics 

1. Objects are not typed, they are simply named by an identifier 

Ex. : There is no DDL, only conventions to designate the objects. For instance, using suffix to de- 
note the kind of the object (e.g. foo.cc refers to a ‘c’ source file, foo.txt to a document, foo.o to 
a binary file, foo.ps.Z to a compressed file, etc.). 

2. Objects are typed using a set of predefined types provided by the PSEE 

Ex.: The objects are characterised by a fixed set of predefined attributes, like its name, author, 
creation date, modification date, status. This set of attribute is given by the PSEE. 




D.1 Product 247 



3. Objects are typed and these types are user-defined. The user can define as many char- 
acteristics as he/she wants for an artifact. These characteristics or attributes are of 
some basic types, like string, integer, float, date, set, boolean. They represent any 
dimension associated to an object that can be selected by the user later on. 

4. Different constructors can be available to define types 

• record structure of basic or stmctured types 

• list of basic or structured types (ordered set) 

• set of basic or structured types (unordered set) 

5. Inheritance (in the 00 sense) is available for type definition 

• simple inheritance 

• multiple inheritance 

D. 1.1.2 Description of Relations between Objects 

1 . The concept is not part of the DDL. There is no way to relate explicitly an object with 
another one. 

2. Relations are expressed via attributes that refer to other objects. Therefore, the rela- 
tion is part of the object definition itself. 

Ex.: Object composition can be supported this way. 

3. Only predefined relations can be used. In particular, there may be the notion of object 
composition. Complex objects can be defined using one or several levels of decom- 
position. 

Ex. : It is possible to create complex objects by usin^ a predefined “is composed of’ relationship, 
or to handle traceability links by using a predefined “depends-on ” relation. For instance, one 
may describe that a configuration is composed of modules, or that a document is composed of 
chapters. 

4 . Objects relation is an explicit concept available in the DDL. The user can define as 
many types of relations as he/she wants, but the characterisation of the relation is 
restricted by the PSEE to a set of predefined attributes. 

5. The characterisation of the relation type is free and the user is allowed to add as many 
attributes to a relation type as he/she wants. 

D. 1.1.3 Granularity of Objects 

Known objects can be only files, or files and smaller elements within files , or files and 
(structured) group of files, or PSEE specific objects, from coarse grain down to fine 
grain 

D. 1.1.4 Management of object life cycle 

1. It is not supported by the PSEE; object life cycle cannot be defined nor handled 

2. A predefined set of states (object attributes with predefined domains) is available to 
characterise the object life cycle 

Ex. : In a configuration management system - an object can appear in a creation state, evolve un- 
der version control status, and finally go into a configuration. 
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3. The user can define the state transition diagram representing the object life cycle 
Ex.: Any document can be first in outline status, then has to go to proposal, reviewed, and final 
status. 

D. 1.1.5 Management of Object History 

1. It is not supported by the PSEE; object history cannot be defined, kept or handled 

2. Versioning of objects is supported 

3. The relevant set of historical information is predefined by the PSEE 
Ex.: The author and date are recorded each time a new object version is created. 

4 . The relevant set of historical information is user-defined 

D.1.2 DML (Data Manipulation Language) 

There are various kinds of operations available to handle objects. 

D. 1.2.1 Basic Operations on Objects 

1. They can be object creation or instantiation, completed by object deletion, modifi- 
cation of the content, object duplication eventually object merge 

2. Specific operators are available to handle list or set of objects 

Ex. : The PSEE may have to handle a list of modules where each module has to be given to a par- 
ticular developer then to a tester. A new module may have to be added to the list “tested”, or 
removed from it,... 

D. 1.2.2 Object Identification or Query 

1 . Query definition support 

a) No query support for any kind of object 

b) Only predefined queries are available, and are based on attribute values 

c) Queries can be user-defined and are based on object attributes 

2. Queries execution principle 

a) Queries are computed statically via the use of index (or other mechanisms) which 
require the use of a computation process off line 

b) Queries are computed dynamically 

D. 1.2.3 Access Control of Objects 

1. The environment is closed (e.g. PCTE). Any object is part of the system, and cannot 
be handled or accessed outside the PSEE. 

2. The environment is open. Objects can be accessed and modified from the outside or 
independently of the PSEE, and the level of integration between PSEE and the out- 
side world is supported. 

D.2 Activity 

In this section we characterise the capabilities of a given process technology to deal 
with activities, their description (model) and their enactment in the real world. 
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An activity can be viewed following several facets, which can be covered to a greater 
or lesser extent by the given modelling approach. 

Among these facets we have: 

• The purpose or goal of the activity, 

• Its functional description - what has to be done in terms of inputs, outputs, action, 

command, or treatment operation, 

• Its behavioral description - how to do it - possibly including a description of what may 

happen during its execution, dealing with error and exception handling, 

• The circumstances, condition and constraints under which the activity has to or can 

be performed, 

• The impact this activity has on other activities, and/or on the environment (objects,...), 

• Its pre-requisite and needed resources (in terms of tools or agents), 

• Its outcome or result. 

Some of these features may be available at the modelling level but not used for enact- 
ment or on the contrary, may not be present at the modelling level and introduced in 
some way by the enactment system. For example, the goal of an activity may appear as 
an informal textual information in the model, not to be used for activity planning. Tem- 
poral constraints on the performance of an activity may not be defined at the modelling 
level but may be specifically introduced at the execution level. 

D.2.1 General 

D.2.1.1 Genericity and Flexibility 

The definition of an activity may be supported in various ways. 

1 . No specific concept is provided for activity description. 

2. A predefined set of activity templates is available. 

3. Activities are typed and the process designer can create as many types as he/she 
wants. 

D.2.1.2 Level of Abstraction 

1. Only one level of abstraction is provided (single and flat view). 

2. An activity can be represented at different levels of abstraction (multiple view 
approach). This can also be considered as the possibility to specify the different fac- 
ets mentioned above within a set of models. 

3. Coherence is insured between the different levels of abstraction. 

D.2.2 Activity goal 

The goal of an activity describes its purpose or outcome independently of any func- 
tional or operational realisation. 
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D.2.2.1 Levels of Definition of the Activity Goal 

1 . The activity goal is not described in any way in the model. 

2. The activity goal is provided as an informal textual information. 

Ex. : The purpose of peer review is to reduce the number of errors left undetected in any activity. 

3. The activity goal is formally described (by using for example predicates typically in 
a goal-oriented approach). 

D.2.2.2 Goals as Pndependent Concepts 

The goals can be defined as independent concepts which are then associated to an oper- 
ational or functional description of activities which allow to achieve them. 

1 . Goals are not managed. 

2. Goals are managed as features dependent on the activity definition (or functional 
part of the activity definition). 

3. Goals are managed as features independent from the activity definition. 

4. More than one goal can be associated to an activity. 

5. More than one activity can be associated to a goal. 

D.2.2.3 Operators Handling Goals 

1 . Operators are available to compose and decompose goals to support different levels 
of abstraction and composition of the activities. 

2. Planning operations can be performed based on goals definition and decomposition. 

D.2.3 Functional Aspects of Activities 

This feature characterises the action or operation to be performed, its input and out- 
put. 

D.2.3.1 Types of Supported Activities 

1 . Operations performed automatically by tools, with no human intervention. 

Ex. : Compile source code, run tests. 

2. An operation that can be performed either by a human or by a computer, depending 
on the available tool support, or by both. 

Ex.: Checking a document - if no speller is available, it can be done by hand. 

Ex. : Reviewing a document by first printing out the document and reading and making notes on 
the paper version. 

D.2.3.2 Form of the Functional Description 

1 . A textual or diagrammatic description, which can not be executed, explains what has 
to be done. 

2. An executable command which is either a request sent to the human agent or a tool 
invocation command. 
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3. An executable program for a step by step control of the processing operations in an 
assisted environment (with for example intelligent support and guidance, Process- 
sensitive SEE for human tasks or very fine grain control of tool processing). 

D.2.3.3 Activity Scope 

The granularity of the modelled tasks may be: 

1. Coarse grain (e.g. software specification). 

2. Fine grain (e.g. tool activation command, request SQL, support for cooperative 
work). 

D.2.3.4 Activity Decomposition 

A refinement of the activity definition from coarse grain levels to smaller grain levels is: 

1 . Not supported. 

2. Provided via a static - hierarchical decomposition, under the form of a work break- 
down structure. Some choices may be available in the hierarchical decomposition to 
identify different types of decompositions depending on some contextual parame- 
ters. 

Ex.: A tree ofta.sks. 

3. Built dynamically by the manual selection of the needed sub-activities by a human 
agent. 

Ex.: Building the work breakdown of a project base from a predefined set of activities using a 
project management tool. 

4 . Dynamically derived or computed by the process support system (e.g. planning). 

D.2.4 Behavioural Activity Description 

The behavioural description of an activity characterises how an activity is executed and 
what may happen during its execution. 

D.2.4.1 General 

The modelling approach may support either deterministic or non-deterministic 
behaviours. 

D.2.4.2 Activity Execution Status 

As part of the behavioural aspects of an activity, the process designer may be allowed 
to specify some internal states of the activity execution. 

1 . There is no concept of activity execution status available in the PSEE, 

2. There is a predefined set of activity execution status managed by the kernel of the 
PSEE (ready for enaction, active, suspended, aborted, killed, terminated,...), 

3. The user can define his own set of activity execution status (delayed, late, critical, ...), 
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4. The user can define how to manage and handle the states transitions (control infor- 
mation is not linked only to the start or end of activity as the two minimal states to 
be handled - suspend, restart, abort, delayed conditions can also be expressed and 
controlled). He can act explicitly upon state transition whether it is kernel or user 
defined states (force a start, a wait or a terminate state). 

D.2.4.3 Exception Handling 

During the performance of an activity unexpected situations may occur. The PSEE 

may offer some support to deal with them. 

1. No specific support for the representation and treatment of exceptional or unex- 
pected activities behaviour is provided. 

2. A default termination state is available to signal any abnormal behaviour, with a 
default treatment or operation to be performed (e.g warning or reporting to a partic- 
ular agent, suspending current process execution). This default action cannot be 
modified. 

3. A default abnormal termination state is provided, and the process designer can spec- 
ify the type of action to be performed in such case. The default action can be mod- 
ified. 

4. More than one abnormal termination state is provided (predefined), each with a ded- 
icated error handling mechanism, and a difference can be made between known 
abnormal termination cases (errors, exceptions, deviation from the normal course of 
execution of an activity) and unexpected or unforeseen problems (incident). 

Ex.: A compilation can fail became of a syntax error. 

Ex.: A compilation fails because of a power failure, or because the source file was deleted. 

5. The process designer can define as many abnormal termination states as he wants 
with a dedicated error handling operation. Theses states can clearly be differentiated 
from the normal course of actions. 

D.2.5 Activity Execution Constraints 

This feature characterises the conditions, events or constraints that can be used to con- 
trol the activity execution, to express under which circumstances an activity execution 

can take place. 

D.2.5.1 Condition Based on the Current Status of the Process 

It does not rely on any other memory of how the process has performed up to now. 

1. On end-user’s request - Manual activation or state transition. This manual activation 
is effectively modelled in the activity definition or it is an activation operation that 
can always be performed, and thus it isn’t or cannot be modelled. 

Ex.: Project manager activates the project initialisation task (manually, on his own initiative). 

2. Upon termination of another activity (limited to only one type of status changes). 

Ex. : Activity xxx has ended. 

3. Upon any activity status changes. 
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Ex. : Activity xxx is delayed. 

4. Upon a restricted set of product status changes. 

Ex.: Document XXX has been created, deleted, modified. 

5. Upon any kind of product status changes. 

Ex.: Document xxx has been validated, upgraded, archived,... 

D.2.5.2 Condition Based on the History of the Process Performance 

It requires an history mechanism at the activity level. 

1. Based on a particular sequence of events that has happened and has been recorded. 
Ex.: 30 bugs have been found on a given module during activity X. 

2. Sequences, number, ordering of past events can be used to express the condition. 
Ex.: The user has done X 3 times without doing Y and another user has terminated Z. 

D.2.5.3 Condition Based on Temporal Events (see section D.6) 

1. At a fixed date. 

Ex.: 14th ofapril. 

2. At a relative date. 

Ex.: Three days after the starting of a particular task. 

3. On a periodical basis. 

Ex.: Every week. 

D.2.5.4 Condition Based on External Events Linked to the Process Performance 

1 . Events related to time consumption and temporal performance. 

Ex.: Alarms related to task duration (delays). 

2. Events related to resource management, consumption and performance. 

Ex.: Alarms due to resource charge overflow, re-allocation of resources, unavailability of re- 
sources. 

3. Events linked to program/tool execution. 

Ex.: Termination signal, failure notification message. 

4. Events generated/provided by human agents. 

Ex. : Incident detection, tasks termination signal. 

D.2.5.5 Execution Constraints and Conditions 

It may be needed that activity execution should obey given constraints. 

1 . No execution constraint can be specified. 

2. Execution constraints can be defined. 

Ex.: During test, error rate must remain below O.2error/KLOC. 

Ex.: During code development, the design document must be in the status “validated”. 

3. Global execution constraint can be defined independently of any activity description. 
Ex.: Total cost of the project must not exceed 0.5MECU. 

4. It may be possible to express execution condition independently of any activity 
descriptions as some general execution constraints. 

Ex.: No activity can be started without the project manager authorisation. 
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D.2.5.6 Instantiation Characteristics 

Some instantiation characteristics may be given to an activity either at the modelling 
or the enactment level; 

1 . An activity can be marked as optional or mandatory, 

2. An activity can be allowed to be executed only once (no possible reactivation), 

3. An activity can be forbidden to have multiple concurrent executions (a new activa- 
tion of the activity is possible only when the previous one is over), 

4. An activity can be defined as having multiple concurrent executions (the activity is 
the set of running instances, and an ending condition for this activity may be that all 
the instances have terminated). 

Ex.: The testing activity is made of several instances running concurrently, each one testing a 
separate module. 

5. An activity can be defined as periodic. 

Ex.: Write a project report every week. 

D.2.6 Activities Composition 

This feature describes the ordering and composition of the different activities. This 
doesn’t cover the cooperation aspects (see section D.4). 

D.2.6.1 Activity Ordering 

1 . Static ordering (serial, parallel) or dynamic sequencing (planning) is possible. 

D.2.6.2 Activity Composition 

The set of activities can be flat or structured hierarchically or as a .DAG.or as a net- 
workor as plans. 

D.2.7 Activity Inputs and Outputs 

D.2.7.1 Activity Pre-requisite and Needed Resources 

Inputs, activity prerequisite and needed resources, and activity outputs are either not 
represented, or specified at instance level, or explicitly specified at model level; they 
can be statically or dynamically declared. 

D.3 Workspace 

This section describes the services that a PSEE should provide for workspace manage- 
ment. 

D.3.1 Concept and Definition 

A workspace is defined as the set of entities and tools used and handled to perform a 
given task. Workspace management deals with the management of the related entities. 
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• At model level, it defines the object types, their representation (format, location, pro- 

tection), their relationships and the tools that must be part of each workspace^ 

• At instance level, a workspace manager must be able to “find” the right object ver- 

sions, to provide these versions in the correct format to the activity and to control the 
workspaces interrelationships when sharing common objects. 

The workspace concept is not always explicit; some PSEEs do not define or support 
this concept. However the notion of a workspace do exist and the following services 
must somehow be provided. 

An explicit workspace concept allows to distinguish the Operating System, network 
and sharing strategies aspects from the higher level process aspects (goal, collaboration, 
...), which are discussed in the other sections. 

We discuss here the two major functions of a workspace: 

1) The objects must be provided to the activities in the form required (the file system 
representation is a major topic). 

2) When concurrent activities are sharing objects, workspaces must provide both isola- 
tion and coordination of concurrent changes. 



D.3.2 File System Support 

In most cases, a workspace includes tools and the file system representation of the 
objects (files) needed to perform a job. The workspace is the support for performance. 
The process support manages an abstract representation of the “real” workspace. 
Different support types for file system workspace can be distinguished. 

1 . There is no direct link between the PSEE and the workspace. The user is in charge of 
making the link itself. 

Ex. : The PSEE says: “Fix bu^ 1 23 on module Clock The user must know where to find “bug 
123” description, and where is located the module Clock i.e. in which file(s) and directory. 

2. The PSEE knows the workspaces, their existence and purpose, but does not build 
them nor does it control their contents. The PSEE does not control the activity per- 
formed in the workspace. There is usually no explicit workspace model. 

Ex.: “Fixbug 123, in file Clock.cc found in workspace under ~AVSBugl23”. The workspace con- 
tains the bug description, all the files needed to fix the bug. However the bug fix activity is not 
controlled. 

3. The PSEE is able to create the workspaces when needed. In this level there is no 
transformation between the objects as known by the PSEE into the corresponding 
files; there are two models: the one used by the PSEE and files. 

Ex.: “Fix bug 123, in Clock.cc found in workspace under ~/WSBugl23” . The PSEE created the 
workspace WSBugl23 from its knowledge of the bug, the configuration, the user and so on. Once 
fixed, the PSEE is able to get the changes performed in the workspace. However, as previously, 
once created, the activity is performed unattended. 



1 . When an explicit Process model exists, it can be seen as a process-model fragment 
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4. The PSEE creates the workspaces and tries to control / automate the performance; 
as for instance to notice that a given test suite was successfully executed. The work- 
space is managed. From this point of view, the PSEE must be able to “translate” an 
action on an object (in the PSEE model) to a tool application on a file in the work- 
space. 

Ex. : Execute the test suite T1 on the configuration in workspace WSBugl23. If successful execute 
T2, otherwise send the problem report to.... 

5. The product model in the workspace is as rich as possible, and if possible, the same 
as the PSEE product model. A formal workspace model exists. Workspace objects 
are also PSEE entities, and if possible indistinguishable, from user and tool point of 
views. 

6. Open / close workspace management. This is a different approach to provide func- 
tionalities 4 and 5. 

A workspace is said close if access to objects (files) in the workspace can be per- 
formed only through the PSEE. The workspace is in the PSEE. 

A workspace is said open when the workspace files are real files in a file system. 
Tools can manipulate them without any change. 

D.3.3 Inter- Workspace Collaboration Policies 

Two or more workspaces may contain the same entities at the same time. ‘Collabora- 
tion’ is the management (storage, recovery, consistency, moving, merging and so on) 
of artifacts/data when shared by different activities. ‘Cooperation’ usually involves 
‘communication’ and ‘coordination’ between processes which is the topic of the sec- 
tion Cooperation (see section D.4). Workspace management is in charge of the collab- 
oration only. 

A wide range of solutions have been adopted by the different PSEEs. In most sys- 
tems, all forms of cooperation are managed explicitly at process model level. A PSEE 
can support different degrees of collaboration between workspaces. 

1 . No concurrent access control is provided. Users are in charge of defining themselves 
their concurrency control policies, independently of the PSEE. There is no support 
for collaboration policies. 

Ex.: In point I and 2 above (see section D.3.2), users are in charge of managing possible con- 
current accesses to module clock.c. 

2. Usage of a locking mechanism. The PSEE, in a way or another, enforces a sequen- 
tialisation of modifications on shared files. Classic solutions include locks (as in 
RCS) or Unix rights set by the PSEE. The implicit imposed policy is sequentialisa- 
tion. 

Ex.: In the example above, files bugI24.doc and clock.cc are protected against another change. 

3. Parallel work is allowed. Merging (assisted or not) is possible. A fixed set of con- 
current work policy is provided. Isolation of workspaces is guaranteed, and collab- 
oration patterns are executed on workspace completion only. 

Ex.: WSBugI23 and WSBugI42 are development workspaces; workspace release_4 is an inte- 
gration workspace. Development and integration are predefined workspace types, with prede- 
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fined collaboration policies. 

4 . Parallel work is allowed and resynchronisation of changes is performed even during 
the execution of the work, controlled by the collaboration policy. Workspaces are not 
isolated. 

5. The user can define himself its collaboration policy, automatically enforced by the 
system. 

Ex.: Changes on headers must be sequentialised, while changes on bodies are resynchronised as 
soon as they are compiled without errors. 

D.4 Cooperation 

Cooperation in its wide dimension includes communication, coordination and more 
complex interactions such as negotiation for conflict resolution. Cooperation can take 
place between processes, between tools, and between processes and tools. Our interest 
in this section is to consider issues of cooperation at a conceptual level. 

D.4.1 Process/process Cooperation 
D.4.1.1 Space and Time Dimensions 

Cooperation between asynchronous processes does not require them to be under enact- 
ment at the same time. Cooperation between synchronous processes requires them to be 
under enactment at the same time. 

1 . Cooperation can take place between processes (or sub-processes) that are asynchro- 
nously enacting at the same geographical location (e.g. the same local area network). 

Ex. : The author of a design document and its reviewer are physically in the same building. During 
the review process, they cooperate in an asynchronous manner by “putting on each other desk” 
new versions of the design document to review and review comments on these versions. 

2. Cooperating processes (or sub-processes) are asynchronously enacting at geograph- 
ically distant locations. 

Ex. : The author of the design document and the reviewer responsible for its review are physically 
distant and communicate via electronic mail only. 

3. Cooperating processes (or sub-processes) are synchronously enacting at the same 
geographical location. 

Ex. : The review of a design document is carried out following the method described by Fagan: the 
author, the moderator and the reviewer “meet” to do the review. 

4 . Cooperating processes (or sub-processes) are synchronously enacting at geographi- 
cally distant locations. 

Ex. : The Fagan review is carried out by video-conference. 

D.4.1.2 Process Data 

1. In cooperating processes data can be private. 

Ex.: Two programmers have each one a private module version; they cooperate to build a new 
configuration (we assume that a configuration is built from these two modules). 

2. Cooperating processes can also share data. 

Ex.: A description of the configuration exists and can be shared by the programmers to build a 
new one. 
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3. Cooperating processes can contain private tasks. 

Ex.: Given a tester, an analyst and a programmer; the tester detects a bug, the analyst fixes it 
and the programmer gives the required modifications in the concerned modules. 

4 . Cooperating processes can ‘share’ tasks. 

Ex. : At a Change Control Board level, after the cost and impact analysis of a change to be per- 
formed, deciding which modifications to do is a shared task. 

5. In cooperating processes, goals can be private. 

Ex. : The tester's goal is to detect bugs, the analyst's one is to fix it in the code while the program- 
mer's goal is to deliver the modified module. 

6. In cooperating processes, goals can be shared. 

Ex. : The common goal of the tester, the analyst and the programmer is to deliver a module at the 
required (and identified) quality level. 

D.4.1.3 Protocols 

1. Cooperating processes may involve cooperation protocols that are predefined 
(defined at the support level) and fixed without possibility of negotiation 

Ex.: During maintenance phase, two analysts are working on bug fixing within a same module 
version: the change propagation protocol is the traditional Check-in / Check-out which is pre- 
defined and does not allow any negotiation between the reviewers. 

2. Cooperation protocols in processes can be predominate with possibility of negotia- 
tion. Negotiation protocols are also predefined at the support level and can be used 
in conflicting situations. 

Ex.: The same bug is fixed differently by the analysts: following the predefined negotiation pro- 
tocol, merging of modifications must u.sually be done on the initiative of the analyst who has be- 
gun his work last. 

3. Cooperation protocols can be customisable without possibility of negotiation. Cus- 
tomisable means that the users (process designer and/or participant) of PSEE can 
adapt the protocol to their needs by parameterizing an already existing structure. 

Ex. : The policy of change propagation on module versions is customisable by the users of PSEE. 
Negotiation protocols do not exist. 

4 . Cooperation protocols can be customisable with possibility of negotiation. Custom- 
isable means that the users (process designer and/or participant) of PSEE can adapt 
the protocols including negotiation ones to their needs by parameterizing an already 
existing structure. 

Ex. : ( cf. Ex. 3 ) Negotiation protocols are customisable too. 

5. Cooperation protocols without negotiation can be defined by the users (process 
designer and/or participant) of PSEE i.e. it exists a language and support for proto- 
col definition. Negotiation is not supported. 

Ex.: Users of PSEE can define their own policy of change propagation e.g. their own Check-in/ 
Check-out. Negotiation protocols definition is not allowed by the language and/or by the sup- 
port. 

6. Cooperation protocols with negotiation can be defined by the users (process 
designer and/or participant) of PSEE. The protocol definition language allows him 
in addition to define its own negotiation protocols. 

Ex. : ( cf. Ex. 5 ) In addition to their own Check-in / Check-out protocol, users use the language to 
define negotiation protocols that they intent to follow in conflict situations. 




D.4.2 Process/tool Cooperation (tool execution) 
D.4.2.1 Tool Activation 

1. “Lexical” level; 
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a) The process sends a string to the operating system, e.g. to the Unix shell. This 
string follows the Unix shell’s syntax. No particular processing nor generation of 
format of this command is done at the process level. 

Ex.: call: ‘cc -c -o toto.o toto.c’ 

h) A symbolic name is associated to a parameterised Unix shell script. An implicit 
semantics is attached to this symbolic name (e.g. compiler). 

Ex.: define: compile — > ‘cc -c $fich’ 
call : compile ‘toto.c’ 

2. “Context-free” level; 

a) A tool is characterised by pre/post conditions as well as relations between input 
and output data. This aims at describing conditions and behaviour during tool exe- 
cution. 

Ex. : Compiler tool has, as an input, a file in the state “edited" and “not compiled”. After compi- 
lation the file status becomes “compiled” or “error”. 

This level assumes that, each time the tool is invoked, there is an automatic control 
which ensures that the effective parameters verify the required properties (espe- 
cially precondition properties). 

3. “Context-dependent” instance level. 

a) Mechanisms, which allow to take into account exceptions related to some data 
inputs or tool instances are provided. Those mechanisms help to express particular 
characteristics or situations due to specific data or components which cannot be 
treated at the type level. 

Ex.: Module foo.c needs a particular compiler’s option in order to produce the binary foo.o 

b) The PSEE can take into account the context (execution environment) of the tool 
in an automatic way. Several aspects can be distinguished; 

• the user characteristics. 

Ex.: Propose to the user its favourite editor. 

• the task type to perform. 

Ex.: Set automatically the -g (debug) option of the cc compiler during development. 

• the resource localisation. 

Ex. : Generate the -I option when modules are not directly accessible ( that is to say when modules 
are not located in the local directory) during compilation. 

• the system (software or hardware) architecture. 

Ex.: Detect automatically Solaris or BSD. 

• the nature of data. 

Ex.: Call the Pascal compiler when input files are coded in Pascal. 

D.4.2.2 Tool/process Interaction 

1 . Data service request. 

Ex. : The process is able to provide the data needed by the tool. 

2. Task service request. 

Ex.: Tasks are executed punctually by the process, when requested by a tool. 
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3. Data information request. 

Ex.: The process localises and evaluates the state of the data to be sent to the requesting tool. 
The process provides the information available in its context and from other tools. 

4 . Task information request. 

Ex.: Tasks states are evaluated by the process and transmitted to the requesting tool. According 
to the state of the task, the tool continues its execution or moves to a waiting status. 

D.4.2.3 Tool Abnormal Termination 

By tool abnormal termination, we refer to all actions undertaken by the process to force 
a tool to stop its execution. Three cases can be distinguished: 

1 . “Lexical” (Tool stopping actions are the same for any tool or user), 

Ex.: Send SIGKILL to the tool’s UNIX process(es). 

2. “Context-Free” (Tool stopping actions are the same for any tool or user but the ini- 
tiative is left to the user). 

Ex.: Ask to the concerned user to stop the design.doc edition. 

3. “Context-Dependent” (Tool stopping actions depend upon the process state). 

Ex. : Explain to the user why she/he must stop design.doc edition and ask her/him to explicitly 
stop the editor 

(i.e. “Project is late. Review Design activity must proceed. Please stop editing design.doc”). 

D.4.2.4 Tool Normal Termination 

By tool normal termination, we refer to all actions undertaken by the process after a 
tool’s (normal) termination. Three cases can be distinguished: 

1. “Lexical” (Tool termination actions are the same for any tool or user), 

Ex.: Signal the UNIX wait termination 

2. “Context-Free” (Different classes of tool can be distinguished). 

Ex.: Remove <f ilename> . * after <f ilename> edition 

3. Context-Dependent (Tool termination actions can be customised for any tool). 

Ex.: Ask if the user wants backup files. If not, remove < filename >~ if < filename > was ed- 
ited by emacs or remove <filename> . % if <filename> was edited by textedit. 

D.4.2.5 Tool Monitoring 

Tool execution can be seen as a deterministic process transforming input data. During 
tool execution, specific and well identified states are reached. Tool monitoring focus 
on the degree of visibility of the process on tool processing states. The following 
degrees can be identified: 

1 . No visible, no modifiable state: 

a) On data: The process can exploit only the output (final) data produced on tool ter- 
mination. 

Ex.: A metric tool provide metrics in a standard format on termination. It is impossible to spy 
intermediate states. 

b) On services: The tool is perceived as a monolithic (black box) service. 

Ex.: Call a metric tool and wait its termination to exploit the produced metric data. 

2. Visible, no modifiable state: 
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a) On data: The intermediate data are visible but not modifiable, 

Ex.: During metric tool execution, the produced metrics are immediately stored 

b) On services: Current tool task is visible. 

Ex. : The process can identify metric tool processing steps: ( data gathering, data processing, etc.). 
3. Visible, modifiable state: 

a) On data: The process can modify tool’s input data or intermediate results. 

Ex.: Metric definition can be automatically changed by the process during tool execution. 

b) On services: According actual needs, the process can choose among different 
services proposed by the tool. 

Ex. : The process can suspend or activate different metrics steps according to the project manag- 
er’s needs. 

D.4.3 Process/tool Cooperation (modelling) 

D.4.3.1 Tool Services 

1. The process perceives the tool services as file transformation functions. The process 
designer must explicitly describe the appropriate shell command. 

Ex.: The compiler is modelled through a Unix Script Shell invoking cc. 

2. The process invokes tool services by explicit messages through a software bus. 

Ex.: Configuration management facilities are invoked according to a “Case Communique” -like 
protocol. 

3. The process designer defines an explicit communication protocol between the proc- 
ess and the tool. 

Ex. : A protocol may be designed between the process and a configuration management tool in or- 
der to automatically produce the corrector’s environment, based on modification requests. 

D.4.3.2 Tool Data 

1. Tool data are perceived as files and the tool’s data model is not explicitly defined in 
the process model. 

Ex.: Compiler is a function defined as following: Compiler: file file. 

2. A tool can be “syntactically” described by typing its input and output data. This 
notion is similar to the signature of functions and procedures. 

Ex.: The compiler tool takes as an input n “src” files and produce a “bin” file: 
compiler ( -inAl, A2, ..., An : see -out A : bin). 

3. The complete dataflow diagram of the tool is described in the process model and 
intermediate data can be consulted or manipulated during tool processing. 

Ex. : The process cooperates with the metric tool during the project and uses its intermediate met- 
ric data according to its needs (The metric tool can be modelled as a particular activity. Metric 
data structures can be modelled as well). 

D.4.3.3 Protocols 

1. Without protocol: 

a) global events, 

Ex.: A process interacts with each tool through predefined events. 

b) customised events. 

Ex. : A process interacts with a tool through a customised event. 

2. With predefined protocol and without negotiation. 
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Ex.: Tool and process interact with a “send and wait” policy to realise a common activity. The 
tool awaits process response whenever it sends a request. The process is thus able to accomplish 
or refuse tool services. In case of refusing, the request is repeated until activity is accomplished. 

3. With predefined protocol and with negotiation. 

Ex. : Same as without negotiation ( see above ) but communication conditions are fixed before tool 
request execution. In case of refusing the request execution, tool request is for instance repeated 
periodically. 

4. With customisable protocol and without negotiation. 

Ex.: The process execute tool request using protocol rules defined in the tool model. Note that 
process is able to accept or not the request. 

5. With customisable protocol and with negotiation. 

Ex. : Same as without negotiation, but communication conditions are considered. Negotiation pa- 
rameters are validated by the process. 

D.4.4 Tool/tool Cooperation 
D.4.4.1 Space and Time Dimensions 

1. Cooperating tools can be local and asynchronous. 

Ex.: Analysis tools and design tools are on the same workstation. 

2. Cooperating tools can be distant and asynchronous. 

Ex.: Analysis tools and design tools are on different sites. 

3. Cooperating tools can be local and synchronous. 

Ex.: A debugger and a compiler are on the same machine. 

4. Cooperating tools can be distant and synchronous. 

Ex.: A debugger and a compiler are on different sites. 

D.4.4.2 Integration Dimensions 

1. Data integration. Cooperating tools can be integrated at the data level i.e. tools share 
information and manage relationships between objects they produce. Tools in a 
PSEE use generally an object base to have / give information about the process. 
Data integration can be done via: 

a) File systems, ex: Unix tools. 

b) Data A\ctionaxit^,ex:Tools share an internal representation such as abstract 
trees 

c) Databases,ex‘ Postgres. 

d) Object bases, ex' PMDB, SKB. 

e) Distributed information bases (repositories), ex. PCTE, CAIS, AD/Cycle 

f) Knowledge bases. ejc.- ALF 

2. Control integration. Cooperating tools can be integrated at control or task (control) 
level i.e. tools are able to communicate by message passing. The PSEE allows tools 
to invoke automatically each others. This could be done via: 

a) Lexical level, ex: Unix shell script. 

b) Programmatic tool interfaces, 

c) Standard calls or Remote Procedure Calls, 

d) Message passing, receiver selection depending on the context,ejc.' Software bus. 
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e) Broadcast message servers, ex: Field and Softbench. 

3. User interface integration. Cooperating tools can be integrated at the user interface 
level. This could be done via: 

a) Presentation level, i.e. tools have a similar external “look and feel” user interface, 
ex :Xlib, Motif and Open/Look. 

h) Command leve, tools have the same basic commands, ex: ‘Cut and Paste’ . 

D.4.4.3 Protocols 

1 . Predefined protocols without negotiation, ex: Softbench BMS. 

2. Customisable protocols without negotiation, ex: Forest strategy tool. 

D.5 Process and Meta-process Support 



D.5.1 Model Definition Support 

This section describes the services offered hy a PSEE in order to support the process 
model definition activities. 

D.5. 1.1 Process Modelling System 

1. User Interface. 

a) Type of the user interface. 

The main characteristic of the user interface is either textual or with menus, or 
graphical, or multi-media 
h) Liaison with the Process Model Language 

The user interface can he independent of the process model language or not . 

2. Concepts supported. 

Three aspects have to he considered: 

a) Quality. 

Is it possible to model quality standards and quality activities (e.g. ISO 9000)? 

• Quality of the product, ex :a document D must follow a predefined format F. 

• Quality of the process 
h) Project management. 

This item covers various aspects among which: 

• Time management, ejc.' Compute the duration of task T 

• People management, ex: right to to perform task T. 

• Resource management, ex: already spent effort (e.g. man months) on task T 

• Project follow-up (see section D.6.4), ex: who is currently working on T? 
c) Production 

Three facets are distinguished: 

• Activity (see section D.2) 

• Product (see section D.l) 

• Organisation (see section D.7) 
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3. Level of integration of the three previous aspects (Quality, Project management, 
Production) 

Various kinds of integration techniques are considered, based on the ECMA refer- 
ence model for integration; 

a) Data integration 

h) Uniform user interfaces, ex: Motif 

c) Control integration 

d) Semantic coherence (e.g. process integration) 

Ex. : Consider the Production Aspect. To be activated, a tool T2 needs data which are produced 
by a tool Tl. Express with your formalLsm the following situations: 

Data integration: Tl produces data ( in a format used by T2 ) and stores them in a repository from 
which T2. extracts its input data. 

Control integration: T2 and Tl communicate via a message server; T2 sends a request toTl and 
Tl sends its results. 

Process integration: Tl terminates and produces its results, T2 is activated automatically with 
these data. 

4. Modularity support, reuse support 

The activity of constructing new models is based on past experience and already 
existing model fragments. Systems may provide different support levels as: 

a) Refinement support 

b) Interfaces separated from their bodies 

c) Search, retrieve facilities; 

• By name or by keywords, ex: Find the model named ‘M’. 

• By example, ex: Find the model which looks like the model M. 

Ex.: By characteristics, ex: Find the models which manipulate the object O. 

Ex. : Find the software process model which describes a process named ‘control’ which contains 
two sub-processes named ‘validation’ and ‘change’. 

d) Fragments merging and composition 

Ex.: Describe that a fragment E is obtained by composition of fragments El, F2, E3. 

5. Model tailoring and adaptation (see section D.5.2) 

Reference models are generic. They have to be customised and adapted to specific 
needs. This tailoring may be performed through several techniques, like: 

a) By encapsulation (e.g. static adaptation to a specific environment) 

b) By instantiation 

c) By parameterisation 

Ex. : Specify for a person P of the project the name of his/her preferred text editor. Is it done by 
encapsulation, instantiation or parameterisation? 

6. Analysis and evaluation of the model 

It is often necessary to assess the adequacy of a model, with respect to the real 
world, before or after exploiting it.be used. For that purpose, the evaluation can be 
static or experimental dynamic or can be done by simulation 

D.5.1.2 Process Modelling Language 

One major component is the language (and its associated formalism) used to express 
the process models. New languages appear regularly. For clarification purposes it is 
important to try to classify them on the basis of their main characteristics. 
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1. Type of the Process Modelling Language 

For instance, the language can he Activity or Goal ,or Product or Role oriented 

2. Coverage of the process modelling language 

a) Support of the technical activities 

h) Support of the managerial and human activities (see section D.7) 

3. Nature of the formalism (user point of view) 

Only textual (including mathematical notations), or only graphical or mixed 

4. Choice between formalisms 

a) Formalism is imposed (only one formalism for each type of modelling activity) 
h) Two or more formalisms available for modelling the same entity 
Ex.: The process designer, the process engineer and the quality engineer can choose their pre- 
ferred formalism. 

5. Baseline of the process modelling language; 

a) Functional approach; HFSP 

b) Graph/net oriented approach; Process Weaver 

c) Procedural approach; Arcadia, TRIAD 

d) Rule-based approach; Marvel, ALF 

e) Reflexive approach; ProcessWise, Spade 

f) Reactive approach (triggers); Adele, Alf, Scale 

g) Planning approach; Epos, Grapple 

h) Multi-agent based approach; Scale 

6. Nature of the enactment 

It can be either interpreted, compiled or mixed 

D.5. 1.3 Model Creation Support 

Constructing models is an activity rather similar to developing software. Assistance 
may be provided to model developers to help them producing ‘good’ process models, 
for example through a method for model development. Various levels of assistance 
exist; 

LMethod is defined, 2; is modelled, 3; is supported by the system itself (enactable) 

D.5.2 Model Instantiation and Enactment Support 

This section describes the services offered by the System in order to support the process 
models instantiation and enactment activities. 

D.5.2.1 Instantiation 

The classical approach is to consider that models have to be instantiated, in order to 
cope with specific environment characteristics, before being enacted. Systems may 
have different approaches and levels of support. 

1. Type of instantiation 
a) Only static instantiation 
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b) Mainly dynamic instantiation (only a static ‘root’ instantiation) 

c) Static and dynamic instantiation 

2. Instantiation support 

a) Direct instantiation (e.g. list of actual parameters) 

b) Instantiation using an interactive language (dialogue) 

c) Existence of instantiation models and associated supports 

D.5.2.2 Enactment 

Once started the process performance and the process enactment should progress 
together in a concerted way. The system is expected to provide services to support 
overall process management. 

1 . Do the process 

a) Effective do, coupling with the performance, guidance, partial automation i 

b) Undo the process 

Ex. : Let us suppose that an activity A provides unsatisfactory results. Is there any possibility to 
go back to the step just before the execution of the imperfect operation? 

c) Redo (resume) the process 

Ex.: After having repair the instance of the process is it possible to resume automatically with 
the new results from the point where the anomaly was detected. 

2. Process done (see section D.6.2). Various possibilities exist based on the existence 
of complete archives of the whole process or archives on demand or tracking system 

3. Help service 

a) ‘What can be done?’ service, i.e. assistance 

b) ‘What happens if 1 do that?’ service, i.e. prediction 

c) ‘How can 1 do it’ , i.e intelligent help service 

4. Process monitoring (see section D.6.4) 

The main concern is the support of the overall monitoring of the process. The qual- 
ity and efficiency of such a support depends on the level of ‘intelligence’ embedded 
in the supporting tool. 

5. System control 

a) Multi-users support (see section D.3) 

b) Security, confidentiality, access control 

D.5.3 Evolution and Elexibility 

This section describes the services offered by a PSEE in order to support the process 
and model evolution activities. 

D.5.3. 1 Process Evolution Support 

The evolution may be supported at different levels, e.g.: 

1 . Analysis and evaluation of the real-world process 

2. Guidelines for the evolution of the real-world process 
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3. Full support (methodology, experience bases, ...) 

D.5.3.2 Process Model Evolution Support 

Models and their instances are subject to evolution. Such evolutions are consequences 
of various situations, e.g. the emergence of new requirements, the detection of devia- 
tions between performance and enactment. Systems may provide support for evolution 
depending on whether it concerns models and/or instances. 

1. Subject of the evolution 

a) Instance evolution 

Ex.: Suppose that during a specific process performance developers have to use more resources 
than allocated. Is it possible to change the instance “on the fly” while keeping the same model? 

b) Model evolution 

Ex. : During a process model enactment one decides to use a new design methodology. Is it possi- 
ble to change the model? 

2. Type of Evolution Mechanism 

Evolution mechanisms may differ deeply in nature depending on the underlying par- 
adigm of the process modelling language, e.g.: 

a) Versioning of models and/or instances 

b) Enrichment or impoverishment 

c) Calling into question mechanism (e.g. non-monotonic inference mechanism) 

d) Basic operations (primitives) for expressing evolutions 

e) Dynamic adjustment, e.g. parameters, process variables 

f) Eull support of the model evolution process (model, language, ...) 

3. Impact of model evolution 

a) On related models and their created instances 

b) On the enactable or enacting instances of the modified models 

Ex. : Suppose the design step is not yet finished when the model is changed in order to support the 
new design methodology. Is this change to be considered only for the instances to be created? Is 
this change to be applied on the current or active instance? Are the dependent models and in- 
stances modified in accordance ( or at least marked as possibly needing some rework)? 

c) On the instances to be created 

4. Interfragment evolution support (consistency checking) 

Evolution of a model fragment may impact on other fragments. This may create 
interfragment inconsistencies. The levelk of support may vary from simple notifica- 
tion of evolution, through inconsistencies detection towards correction of inconsist- 
encies, immediately or following transitory states and specific procedures 
Ex. : Suppose when instantiating a model that two programmers ( PI, P2 ) are assigned to the cod- 
ing of respectively the modules MI and M2. During enactment it is decided to reduce the number 
of developers to only one programmer (PI ). The responsible of the activity can decide to maintain 
temporarily the programmer P2 for efficiency reasons, e.g. because the development of the mod- 
ule M2 is almost finished. Express how these transitory states are supported. 

5. Evolution evaluation 

Any model or instance evolution results in a new model or instance. In order to gain 
experience and expertise one may envisage to assess the relevance of the performed 
evolution. This can be supported in different ways, e.g.: A priori or A posteriori 
impact analysis, and/or support for packaging experience 
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D.5.3.3 Evolution Management 

Models are software entities which can be assembled, combined, ... and which exist in 
several versions like source modules do. Models (fragments) have to be managed. 

1. Management of versions (models, fragments, ...) 

Ex.: Find the version of a module M created by John (author = John) before June 1992 (date < 
92-06-01 ) 

2. Management of configurations 

Ex.: Create an official configuration for a Unix system with components created before (une 
1992, i.e. all components of the configuration must satisfy the constraints: state = official, date 
< 92-06-01, system = unix 

3. Instance management, i.e. associate instances with versions of models 

Ex. : After having updated a process model instance associate it to the new version of its process 
model 

D.6 Process Tracking and Time Constraints 

This section addresses the issues related to process tracking: monitoring, traceability 
and visibility. Aspects about time constraints are also discussed in this section. 

D.6.1 Time Constraints 

Four levels can be identified starting from the less to the more generic. 

D.6.1. 1 Local Host Time 

It is the lowest level where time setting is done according to absolute time. The instant 
<T> is expressed using the operating system local clock. 

Ex. : <T> = Fri Jul 29 13:56:24 MET DST 1994 

D.6. 1.2 Advanced Time Management 

A more or less complex structure is provided for expressing time in different forms. 
This structure may be manipulated through operators (comparison, addition, etc.). 

In addition to absolute time, other forms for expressing time might be: 

1 . Relative: <T> is determined given another instant <T0> 

Ex.: <T> = 12 hours after <T0> 

2. By interval: <T> may occur within an interval of time. 

Ex.: Perform a given activity the <D> day; understand “<D> day between OHOO and 24H00”. 

3. Periodically: <T> occurs following a chronological cycle. 

Ex.: Perform a given activity at the beginning of every month. 

4. Event-based: <T> is valid when an event occurs. 

Ex.: Perform activity A2 as soon as A1 is finished. 

5. The different options described above may be combined. 

Ex.: Each time activity <A1> is started, perform activity <A2> 24 hours later on (periodic/reT 
ative/event-based ). 
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D.6.1.3 Reasoning within a Time Scale 

This level offers the ability to reason with respect to a particular time scale. This aspect 
is important and may lead to consider the following factors among others: 

1. Geographic: time lag, universal time vs. local time. 

Ex.: A process running on dijferent machines localised at very distant sites (dijferent countries). 

2. Human: Gregorian vs school calendar, working days, etc. 

Ex.: An activity which needs 3 days effort (logical time) may last one week (physical time). 

D.6. 1.4 Time Meta-model 

It is the ideal level allowing to define and customise one’s own time system. 

D.6.2 Traceahility 

Traceability addresses the techniques used within the PSEE to systematically record 
information about events or actions that may occur during the process execution. All 
types of recorded information will pertain to the history of the enacting process. Such a 
history may be viewed as a function of time and constitutes a means that the monitoring 
service may rely on for capturing information 




Building and maintaining a history lead us to consider the questions of ‘what’ to 
record, ‘when’ and ‘how’ to do it. The quality of a history manager lies in its ability to 
answer these questions in a satisfactory way. 

D.6.2.1 What 

The matter here deals with the capability the system may provide for identifying the 
information to be recorded. Two cases can be distinguished: 

1 . The types of information to be recorded are well-defined. There is no way to trace 
other types of information unless in a hardwired manner. 

Ex. : In Adele, the author, the date, and a comment are stored each time a file is modified. 
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2. Based on a model, the types of information to be recorded can be identified and 
described according to the user needs. 

3. The model is context-sensitive: the same change is recorded differently depending 
on the context. 

D.6.2.2 How 

History information may be stored: 

1 . In bulk, ex: All information is dumped in text files. 

2. In a structured way but with respect to a predefined (rigid) organisation. 

3. According to a user-defined organisation. 

D.6.2.3 When 

When history information is stored can be determined either: 

1 . In a hardwired manner 

2. Or based on a separate model, ex: It uses triggers attached to the objects to be 
traced. 

D.6.3 Visibility 

This topic addresses the facilities a PSEE can offer for defining visibility and scoping 
information associated with enacting processes. The objective is to determine which 
portion of an enacting process state (including product artifacts it is producing or mod- 
ifying, and history as well) may be visible, and if possible provide control over when 
and how these states are visible. 

D.6.3.1 Global Visibility 

Only full visibility is provided with bare rules enforcement. 

D.6.3.2 Restricted Visibility 

Sub-processes and actors operate according to a certain visibility (scope, access 
rights). This visibility can be determined depending on the following criteria: 

1 . Role. The visibility may differ depending on the user role. 

Ex. : The project manager, the developer or the quality expert are not supplied with the same 
types of information and access rights when using the monitoring service (see section D.6.4). 

2. Activity. An activity must specify which regions of involved data are visible to other 
activities.ejc.' Coordination policies between activities can be enforced on the basis 
of sub-database visibility (see section D.3). 

3. Tools. Cooperation between tools may rely on the integration of visibility features. 
Ex.: Propagation of information and mapping between tools formalisms. 

4. Naming, ex.' File system naming V5 database naming. 
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D.6.3.3 Modular Visibility 

The visibility can be described at different levels of abstraction. 

Ex. : For monitoring, the pro ject manager may need general information about the process execu- 
tion ( comparing to the developer). In this case a large-grained description should be more ap- 
propriate than a detailed one. 

D.6.4 External Process Monitoring 

Monitoring is the activity of observing the evolving enactment state of the process. The 
practical objective is to assist the user (typically the project leader) against process devi- 
ation. To achieve this objective, the observation should be carried out on the basis of all 
relevant information (or metrics) that can be captured during the process performance 
from whatever involving parts of the PSEE, be activities, products, performers, or tools. 

What are the types of information, when and how they are to be captured as well as 
how they are to be analysed and further presented to the user are all important issues 
that should be tackled for monitoring support perspective. 

Monitoring may likely need traceability and visibility as shown in the figure below. 




^ uses 




Different levels of assistance over monitoring are identified depending on the ability 
of the PSEE to answer the related issues. 

D.6.4.1 Informal 

No support is provided for process observation; all is done manually. 

Ex.: Use forms for tracking developers’ efforts. 
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D.6.4.2 Predefined Support 

Some functionalities are supported for monitoring but the description of data to be 
observed and the needed mechanisms for capturing these data (when, how, etc.) are 
integrated into the process (or/and product), somewhat in a hardwired manner. 

D.6.4.3 Model-based 

A model is provided for describing the measures (what) that are to be captured with 
associated mechanisms (how and when). 

Ex.: The metrication model based on GQM (Goal/Questions/Metrics) approach. 

D.6.4.4 Interpretation Support 

In addition to a measurement model, a quality model is provided to assist the user fac- 
ing process deviation. Two modes of assistance can be envisaged: 

1 . Passive: The system detects an anomaly but no decision making support is provided 
towards how to prevent from possible deviation. This aspect is completely left to 
the user. 

Ex. : When a developer spends more than 3 days fixing one bug, send a notification to the project 
manager. 

2. Active: The system can react towards process deviation, at least by giving sugges- 
tions about how to manage low critical situation. 

Ex. : If analysis effort exceeds the estimated rate by 1 0%, start immediately the development ac- 
tivity. 

D.6.4.5 Important Issues 

Besides the levels stated before, the following aspects should be considered: 

1 . Where the data to observe stem from? 

from the process (directly)?, from the product (directly)?, from the history?, from 
metrics defined to track process and product evolution for quality perspec- 
tives?, or from 

d) the quality model if supplied? 

2. How these data are to be gathered? 

a) manually, extforms to be filled in. 

b) semi-automatically, extentering information through interactive dialogue. 

c) automatical!, ex: Logiscope. 

3. When the data are to be gathered? 

a) on specific events, ex: when developer X finishes the integration of module Y. 

b) on generic events, ex:Each time a specification document is approved by the 
project manager... 

4. How to present or display the captured data? 

Is it textually, or graphicall, ex: Pie-chart, Bargraph, etc. or is it possible to define 
and customise the interface? 
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D.7.1 Human Aspects 

This section describes the features needed in a process support system to cope with dif- 
ferent aspects of human behaviour. Basically, these aspects fall into two categories: the 
need for customizing processes to take into account various human factors, and the need 
to detect and adapt deviations between models and processes as they are being enacted. 

D.7.1. 1 Customisation 

Customisation is concerned with the modifications of (generic) process models that are 
done in order to cope with specific aspects related to individuals or the organisational 
context in which they operate. 

1. Manual individualisation of tools: allows a user or a group of users to re-define the 
tools used in specific tasks. 

Ex. : Changing the compiler or text editor used. 

2. Automatic individualisation of tools: allows users to define generic modifications 
that are automatically applied in all cases. This includes platform dependent tool 
mappings. 

3. Individualisation of processes: allow a user or a group of users to re-define the proc- 
ess in which they participate. One can imagine different levels of modifications, from 
changing the exit criteria (post conditions) of an activity, to changing the process 
flow (see section D.5.3). 

4. Process refinement: a user who receives a task which has been modelled as a leaf 
activity can define a local sub-process model that describes how the task is to be 
enacted. 

D.7. 1.2 Deviation 

Human activities tend to deviate from the predefined deterministic behaviour which is 
the usual underlying assumption of process models. The reasons for such deviations are 
many, for example: humans learn by doing, which means that experience gained from 
earlier problems influence the way a new problem is solved; humans are creative and 
goal driven and tend to experiment with new ways to work. A more subtle, but certainly 
important aspect involves conflicting goals (e.g. satisfy your boss, satisfy yourself or 
satisfy your colleagues). 

If a process support system is to take into account these particularities of human cri- 
teria, it needs to incorporate functionalities to: 

• Allow deviations that conflict with the “ideal” way of working as expressed by the 
process model. 

Ex. : Refusing a piece of work, modifying the constraints put on a piece of work, or introduction of 
“short-cuts” in the process. 

• Detect what human operators actually do as compared to what they are expected to do. 

• Synchronise the enactment of models to the process as it is performed in reality. 
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1. Deviations: 

a) No deviations allowed. This level corresponds to what is usually termed “process 
enforcement”. On this level, the system disallows all actions not explicitly 
allowed by the process model. 

b) Certain additional actions allowed. This means that the user may perform any 
activity which is not explicitly forbidden. This level, usually referred to as “pro- 
scriptive process management”, can be compared to how access mechanisms are 
used to enforce policy in operating systems by restricting access to tools and 
information. 

c) Any additional actions allowed. On this level, which corresponds to what is usu- 
ally termed “prescriptive process support”, the user is guided by the process 
model to the “best practices”, but may choose to work differently, e.g by invok- 
ing tools and accessing information in a way not controlled by the process man- 
agement system. 

2. Detection: 

The fact that deviations are allowed does not mean that they are accounted for by the 
process management system. For example, if a user has chosen to produce a document 
earlier than suggested by the process model, this does not mean that the process man- 
agement system will take this into account, later when the process has reached the state 
where the document should be produced. In order for this to work, the process man- 
agement system needs to detect the deviation and to re-synchronise the process model. 

a) No detection. Human behaviour is not evaluated (people are supposed to do what 
they are asked to do and at the right time). 

b) Evaluation. Human behaviour is evaluated: the process support system has 
means to detect a gap between what has been done and what was modelled (see 
section D.6.4). 

c) Prediction. Human behaviour is predicted: the process support system has means 
to predict discrepancies between real and modelled human behaviour, based on 
previous experience from similar situations. 

3. Synchronisation: 

a) No support for synchronisation of models with respect to process enactment. This 
means that the user needs to “simulate” behaviour to force the correct changes in 
the enactment state. Such simulations may be quite complex and sometimes 
impossible. 

b) Manual adaptation supported. Instances and/or models may be manually modi- 
fied (see section D.5.3). 

c) Automatic (post)-adaptation (“Resynchronisation”). The process support system 
provides facilities for automatic adaptation of instances and/or models in 
response to detected discrepancies. This level requires detection at least at the 
level 2 (“Evaluation”). 

d) Anticipation. The process support system provides facilities for automatic adap- 
tation of instances and/or models when discrepancies are predicted. This level 
requires detection at the level 3 (“Prediction”). 
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It should be noted that there are several ways these levels can be combined. For exam- 
ple, it can be meaningful to provide detection at level 2 (“Evaluation”), while only sup- 
porting synchronisation at level 1. In this case the system could react to detected 
discrepancies by alarms or by invoking explicitly programmed exception processes. 

D.7 .2 Organisational Aspects 

The term “organisation” may have different connotations. Here we let the term refer to 
stmctural (static) aspects of organisations/projects (positions, roles, reporting, etc.). 

The following notions can be identified as different facets of organisations, and need 
to be represented within the process management system: 

1 . Position: place-holder for person in the organisation structure. 

2. Reporting structure: who reports to whom in the organisation. This is usually defined 
in terms of relationships between positions in the organisation. 

3. Job. Defines a job, such as engineer, that characterises the employment conditions of 
staff. Staff with the same job, may appear at different positions in the reporting struc- 
ture. 

4. Role: defines responsibilities in a certain context (e.g. an organisation, a project or a 
task). Different individuals, holding the same job (e.g. software engineer) may play 
different roles in the same process (e.g. producer/reviewer). 

5. Staff. The individuals who are part of the organisation. 

6. Competence. Defines the various human qualities that are significant to the work in 
the organisation. Competencies are used to qualify positions, jobs, staff, and some- 
times roles. 

D.7 .3 Cost and Benefits of Process Support 

Costs and benefits from using a process management system are important parameters 
when evaluating the interest for an organisation to introduce computer supported proc- 
ess management. Cost vs. benefit may also look quite different between different sys- 
tems. For example a system that is difficult to program, but which requires only cheap 
computing resources during enactment will have an initial cost that is high, but the total 
cost will tend to grow less rapidly when deployed on a large scale. 

Cost and benefit measures and analyses are not functions supported by a process man- 
agement system (even if this would be a great idea!), but are nevertheless important 
attributes, that need to be compared between different systems. 

D.7.3.1 Initial Investment 

There are many different cost aspects related to software processes. Here, we limit our- 
selves to costs related to the investments in process (technology). The following aspects 
of such costs can be identified: 
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1. Total investment cost. This involves cost for: 

a) equipment 

b) basic software (process management system) 

c) software process design (identification and specification of processes) 

d) software process implementation (expressing process designs in terms of execut- 
able process models) 

e) integration with other software engineering services 

f) software process enactment (cost for using computing resources) 

g) user training 

h) maintenance 

2. The return-on-investment can be expressed as a cost/benefit function which shows 
how different degrees of investment provide different degrees of measurable bene- 
fits. This function can look differently: 

a) It can be (but rarely is) linear. 

b) It can be of type exponential (or nearly exponential), meaning that initial invest- 
ments give little return, while bigger investments rapidly result in very high 
returns. 

c) It can be of type logarithmic (or nearly logarithmic), meaning that initial invest- 
ments pay off very quickly, while larger ones provide little or no additional pay- 
off. 

Before considering an investment, the desired cost/benefit-function must be ana- 
lysed. 

D.7.3.2 Initial Cost vs. Cost of Maintenance of the Process 

A particular situation is when the investment cost is not motivated by the return from 
the enacted process, but from the fact that the process changes very frequently (i.e. the 
costs for training and for infrastructure modifications are high compared to the costs 
for running the process). 

D.7.3.3 Investments in Process vs. Investment in Process Support 

One must distinguish between the cost related to the (new) process itself (such as train- 
ing costs) versus cost related to the enactment of the process (i.e. cost for the enactment 
infrastructure). Consider for example the aspects of “do the right thing” (i.e. be effi- 
cient) versus “do the thing right” (i.e. be effective). The former benefits mostly from a 
good process, while the latter mainly benefits from good process enactment. 

Process evolution usually relates to both these aspects, which (at least in theory) 
could be treated separately, so that each evolutionary step should be considered either 
as a step towards better efficiency or towards better effectiveness. Understanding the 
cost/benefit ratios for these two aspects in a given situation seems to be a key issue in 
order to direct process evolution in the most optimal way: when should investments be 
in process (i.e. “thinking”) and when in enactment (i.e. “technology”). 




Glossary 



A number of papers dealing with software process termilonogy have been exploited in 

building this glossary, and the interested reader may look at [Feil93, Lonc93, Dows94, 

Conr94a, Fugg94]. 

The two-letter key classifies the term: UD = universe of discourse, PM = process 

models, MP = meta-process, En = environments. 

Activity (UD): An atomic or composite operation or step of a process that contributes 
toward the achievement of a process goal. It usually aims at generating or modifying 
a given set of artifacts. An activity has associated procedures, rules and policies. 

Activity model (PM): The sub-model that describes activities in term of the associated 
procedures, rules and policies. 

Agent (UD): An active participant in a process, either a human performer or a tool. 

Artifact (UD): An outcome of the process. It may be a required result of the process or 
some other piece of information that facilitates and supports the process. An artifact 
may be composed of other artifacts. For example, a software product may be seen as 
composed of the software modules, the documentation, etc. 

Assistance (PM): Direct support to actual performers in a PSEE, i.e. control of the per- 
formers’ initiatives, coordination of activities, support for cooperation, automation, 
guidance information, etc. 

Atomic item (UD): An elementary artifact. 



Customisation (MP): The act of refining a (generic) process model to tailor it according 
to the specific needs of the organisation. Customisation may be a substantial part of 
the meta-process. There usually are different layers of customisation, at increasing 
levels of detail and formality. The ultimate customisation leads to an enactable model 
— see Instantiation. 



J.C. Derniame, B.A. Kaba, and D. Wasted (Eds.): Software Process, LNCS 1500, pp. 277-307, 1999. 
© Springer- Verlag Berlin Heidelberg 1999 
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Directions, (PM); The instructions on what to do, and how and when do it in an activity. 
In a process model, directions apply to human as well as to tools. They reflect the pol- 
icies, rules, and procedures that are recognised as being valuable to the company. 
They express objectives and constraints and they may provide guidance on carrying 
out the activitiy 



Enactable process model (PM); A process model ready for enactment, its customisation 
being completed. 

Enactment (PM); The act of interpreting/executing an enactable process model. 
Enacting process model (PM); A process model under enactment. 



Generic process model (PM); A model of the process which can be customised into sev- 
eral diffemet instances. It provides organisations with general guidelines on software 
development. Classical life-cycle formalisations are examples of generic process 
models. 

Guidance (PM); Set of facilities to help actual performers in a PSEE, such as informa- 
tion on the current state of the process, the meaning of decision points, answers to 
questions like “What could be done?”,“How to do it?”, “What if I do this?”, “Why?” 
etc. 



Instantiation (MP); The act of transforming a process model into an enactable model. 
It is a special category of customisation. 



Life-cycle model (PM); An abstract semi-formal representation of the software process. 
A more appropriate, life-cycle representation. Well-known examples are the water- 
fall, spiral, and transformational models. 



Management process (UD); The process managing the production process . 

Meta-process (MP); The process for definining, monitoring and evolving of usually 
enacting process models. 

Monitoring (PM); Observation of the process, to gather information and measures on 
its specific characteristics. 
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Organisational model (PM); The sub-model that describes the organisaion chart of a 
business, e.g. roles along with their properties and hierarchical dependencies among 
roles. 



Performance (PM); The working of people and machines in the real world; in the per- 
spective of this book, their activities are controlled to a greater or lesser extend by a 
PSEE. 

(or not at alljPerformer (PM); A human agent in a process. 

Process Designer (MP); The role in the meta-process that is responsible for providing 
the process model and for tailoring the PSEE supporting the process. 

Process Engine (En); The interpreter/executor of a process modelling notation. 

Process Evolution (MP); The result of the operations performed within the meta-proc- 
ess to modify the process and (in reflexive processes) the meta-process itself. 

Process Manager (MP); The role in the meta-process that is responsible for process 
implementation and assessment, e.g. for transforming the customised model into an 
enactable one, and collecting data on its performance. 

Process model (PM); The purpose of a process model is to abstract what is common in 
several projects, i.e. in a family of enactments. The process family is described in 
terms of the common stmcture of activities, the organisation of the products, etc. A 
process model is expressed in a suitable process modelling notation. Process models 
are usually given at increasing levels of details; see life-cycle, generic, customised, 
enactable and enacting model. 

Process (modelling) notation (PM); A formalism to express process models. 

Process-sensitive SEE (En); A Software Engineering Environment is process-sensitive 
(i.e. it is a PSEE) when its architecture is based on a process engine that,in enacting 
a process model, controls the production technology in use. It comprises tools to mon- 
itor, to analyze and evolve process models. 

Process Support (En); A process model and the appropriate PSEE to enact it. 

Process Technology (MP); The set of technologies which support the defining, observ- 
ing, analysing, improving, and enacting of software processes 

Process Technology Provider (MP); The role responsible for providing the integration 
technology enabling process modelling, enactment and improvement. 

Product (UD); The set of artifacts to be developed, delivered and possibly maintained 
in a process. 

Product model (PM); The sub-model that describes the product of a process, e.g. its 
type, structure, properties, and the relationship among its components. 
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Production process (UD): That part of the process dealing with production and main- 
tainance of the product, as opposed to the management process (see Management 
process). 

Project (UD): The process carried out to produce a specific product, usually involving 
temporary organisational arrangements. 



Resource (UD): An asset needed hy an activity to be performed. 

Resource model (PM): The sub-model that describes the resources, either needed by or 
supplied to a process, e.g. their types, relations, structure, and properties. 

Role (UD): The set of responsibilities governing the behaviour and skills expected of an 
agent of the organisation. 

Role model (PM): The sub-model that describes the roles involved in a process, provid- 
ing their types, relations, structure, and properties. 



Simulation (PM): Mechanical interpretation of a process model without actual perform- 
ers, tools or data ( i.e. in a simulated context). 

Software Development Process (UD): All the real-world elements involved in the 
development and maintenance of a software product, i.e. resources, activities, arti- 
facts and organisation. 

Software item (UD): See Artifact. 



Tool (UD): Computer program supporting or automating part of an activity. Tools are 
resources characterised by the operation they implement. 



Validation (PM): The process of evaluating the useful properties of a model, by inspec- 
tion, simulation or test. 

Verification (PM): The process of formally proving useful properties of a model. 

View (PM): The particular approach to a software process conveyed by a (sub-)model. 
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Conr94h, Dem94] are closest to the terminology used in this book. [Feil93, Lonc93] consolidate 
terms as they have heen used. 
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ess assessment. Bootstrap [Boot93,Kuva94] is a European development of the SEI approach, 
while Spice [Rout95] links this with international standards work leading to ISO-15504. 
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with the use of metrics in software process improvement. In this there is a similarity with both 
Humphrey’s CMM work, and his later work on the Personal Software Process (PSP). PSP is 
described in the book [Hump97] and the paper [Hump96]. 

Meta-Process 

Process assessment and process improvement are key ideas which feed into the work on evolving 
the software process. Another impetus comes from Lehman’s work [Lehm91] which addresses 
the inevitable uncertainty in knowing the full effect of applying software in a real-world context. 
The motivations for a meta-process are distilled from experience in large-scale, long lasting soft- 
ware development in [Warb89], and at a more project-oriented level in [Madh91]. [Conr94b] con- 
centrates on concepts in this area. 
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papers. 

The key research papers from a software process perspective are [Band96, Hard93, Goda95, 
Kais92, Nodi92]. Three books dealing with issues of advanced database systems are [Banc92, 
Elma92, Goda93c]. 

Human Aspects 

[DeMa87] is a very stimulating and readable book on human and organizational aspects of soft- 
ware development. As software development is a group activity, much reseach on the use of com- 
puter systems to support such work (CSCW) is relevant to PSEEs. Greenberg [Gree91] provides 
a collection of recent research papers in the CSCW area. Key research papers which have looked 
at software process technology and modelling from a human perspective are [Curt88, Wast94, 
Perr94, Band95]. 
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There are a number of references which deal with domains related to the software process: 
[Dave93, Hamm93] - BPR [Gree91, Baec93, Band95] - CSCW [Macl90, Simon69] - Design 
[McLe90] - Management Information Systems [Seng90] - Organizational learning [Feig91] - 
Total Quality Management. 

[Warb99] describes a process approach to designing business systems. It incorporates many ideas 
developed through work in the software process area. 
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Workshops, Conferences 

There are a number of published workshops and conferences which tackle software process 
issues: 

The European Workshops on Software Process Technology, have since 1992 been published in 
the Springer LNCS series [Dern92, Warb94, Scha95, Mont96, Gruh98]. 

The International Workshops on Software Process Technology are published by IEEE Computer 
Society Press. A standard problem was the focus of ISPW-6 [Kell91], this has been further 
developed to the problem in ISPW-9 [Pene94b] (see Appendix A). The most recent workshops 
are: ISPW-5 [Perr89], ISPW-7 [Kata90], ISPW-8 [Scha93], ISPW-9 [Ghez94], ISPW-10 
[ISPW96]. ISPW-1 1 took place in Illinois, USA in June 1998. The emphasis in these workshops 
is on short papers which reflect current research. 

The International Conference on the Software Process is also published by the IEEE Computer 
Society Press. The First (ICSP-1) in Redondo Beach, USA took the theme of Manufacturing 
Complex Systems [Dows91]. The Second (ICSP-2) in Berlin, Germany took the theme of Con- 
tinuous Software Process Improvement [Oste93]. The Third (ICSP-3) in Reston, Virginia took 
the theme of Applying the Software Process [Perr94b]. The Fourth (ICSP-4) in Brighton, UK 
took the theme of Improvement and Practice [ICSP4] . The Fifth (ICSP-5) took place in the USA 
in June 1998 on the theme of Computer Supported Orgaizational Work. 

There have also been software process sessions at recent International Conferences on Software 
Engineering (ICSE). 

The September 1991 issue of the Software Engineering Journal included several software proc- 
ess papers including [Lehm91, Madh91, Mins91]. 

The December 1993 issue of IEEE Transactions on Software Engineering was a special issue on 
Process Evolution [S-I93]. 

A number of recent papers have appeared in the ACM Transactions on Software Engineering 
and Methodology [Sutt95, Ambr97, Jacc99]. 
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